Public SourceMage Discussion List

[Paul Mahon <dufflebunk AT dufflebunk.homeip.net>]

There is some facility for spells that fail dependencies, although
currently nothing happens to them. There's a function in libdepends,
remove_dependees or something like that and I believe it even passes the
names of spells back to cast which didn't pass the dependencies. 

I think this is the case, but I'm away again and don't have access to
the SMGL source ATM.

On Thu, 2004-05-13 at 00:08, Andrew wrote:
> When deciding about stuff like this i try to weigh in the amount of work
> with the amount of goodth it will create for each option along with
> future implications of solving a problem a particular way. Then compare
> it with other things that need to be done.
> 
> The first option is to make special grimoires for non-x86 architectures.
> This is a fairly low effort ordeal, we just have to identify spells that
> only cast on certain architectures and put them in this special stripped
> down grimoire. Then get all our non-x86 users to add that grimoire to the
> front of their grimoire list. The also lets us mask off certain spells
> from certain architectures, for example mpg123 fails on ppc, and probably
> other little endian machines, but should be fine on non-x86 big endian
> machines (or am I getting big/little messed up?) so in the ppc grimoire
> we can make a stripped down version of that spell that fails in DEPENDS
> or something that informs the user of whats going on. We can even have
> different versions of a spell for different architectures if the build
> process is significantly different. Theres other interesting things you
> can do this way I haven't really touched on.
> 
> The problem then is we lose our main grimoire heirarchy of devel -> test
> -> stable for those spells. But we basically threw that out for z-rejected
> and games, so adding a few more wont be such a big deal. There may be
> some cooler p4 tricks we can use to make this whole process better. In
> any case its a fairly minor pain.
> 
> Second option was to add an x86 only grimoire as well, this has the
> added benefits of 'masking' stuff off for x86 architectures. But has the
> added overhead of convincing every new user to do this. One way around
> this is to make sorcery add it for the user on upgrades or something.
> 
> The problem with both these is we are fairly commited to them, theres
> no easy way to revert everyone back if we come up with a better solution.
> 
> As for the third option, we teach sorcery about platform dependencies.
> 
> Theres two parts to this prooblem. The first is implementing a function
> during dependency groveling to determine if a spell is castable on the
> current platform, if it is then great, if not then the spell fails its
> dependency groveling.
> 
> Which leads me directly into the problem that I've been wrapping my
> brain around for several weeks, which is, then what? What do you do
> when a spell fails to have its dependencies fulfilled? This is directly
> analogous to when a spell fails to build, and we use make for solving
> that side of things. Currently we dont really do a whole lot when a spell
> fails to have its dependencies fulfilled, mostly because it hardly ever
> happens except for in cross grimoire cases.
> 
> The first part is pretty straightforward, we just need a reliable way to
> determine the local platform, then decide on some semantics for explaining
> to cast what platforms are valid (all platforms, all platforms but these,
> or only these platforms). Then we write a function that implements
> those semantics. Then we jam that function into private_run_depends,
> right before the call to run_prepare, and we're done.
> 
> The second part will be part of my grand-master-plan anyways.
> When a spell doesnt get its dependencies fulfilled we can crawl back up
> the depends tree and prune things off as needed, choose other providers,
> turn off optional_depends, save disconnected portions of the tree, lots
> of cool stuff. Doing this opens the door for cross grimoire depends,
> removing make from cast, and all sorts of other interesting things can
> happen more easily. Ultimately giving us more freedom and control (this
> is a good thing).
> 
> IMO theres problems with both methods, so I could go either way.
> Im doing the second part /anyways/ so I cant help but point out how easy
> it is to christmas tree it in.
> 
> -Andrew