Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Architecture-dependent spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Architecture-dependent spells
  • Date: Wed, 12 May 2004 21:28:35 -0700


You are correct, its just all it does is go one level up and thats about it.
No wandering back down other parts of the tree, etc. *shrug*

-Andrew

On Thu, May 13, 2004 at 12:25:57AM -0400, Paul Mahon wrote:
> 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

--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | |
|Sorcery Team Lead, Porting Team Lead | |
|Grimoire Guru ham/smgl | ftp://t.armory.com |
|Author and Maintainer of Prometheus | |
--------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page