Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

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