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: Thu, 13 May 2004 11:53:56 -0700

>
> I'd like a slightly different approach - one that allows me to solve bugs
> like
> 5485 [0] without much trouble, and that would be sorcery allowing the spell
> to
> choose the action according to the arch. It could be as simple as a ARCH
> file
> with lists of different override spell files by architecture [1], using the
> default ones where not specified; it might be more complicated, with sorcery
> functions called to check the architecture inside every spell file that
> needed
> checking.
> What do you think?
>
> [0] http://bugs.sourcemage.org/show_bug.cgi?id=5485
> [1] a example of the file might be structured like this:
> ---------------------
> x86_64=DEPENDS.x86_64,DETAILS.X86_64
> PPC=BUILD.PPC
> ---------------------

What you're describing is almost a reason for going with the multi-grimoire
approach. Having different files with different extensions for each arch
is possible, but would be a lot more work :-/ The easy way out from there
is to then provide a function for one to get the definitive platform type,
then use that in BUILD or PREPARE.

On the other hand you can easily create another spell called perforce-ppc,
make it provide PERFORCE-CLIENT, and make the other perforce (x86)
spell provide PERFORCE-CLIENT as well. However, this is probably going to
come up for most z-rejected spells since so many of them are binary. Id
be in favor of making seperate z-rejected grimoires for each architecture
since the spells by nature are going to be different.

My stance at this point though is that we only have a dozen or so
(non-z-rejected) spells that are platform dependant, we dont have a
huge ppc/sparc following (yet), and most users are smart enough
to not compile mac-fdisk on x86. So theres not a lot of justification
for implementing this right now as a new sorcery feature. I think we
should continue discussing this though and come to a consensus on what
we want the solution to be, and later when we have more important stuff
done and/or it becomes a bigger issue, we can implement it.

-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