Skip to Content.
Sympa Menu

sm-discuss - Re[2]: [SM-Discuss] sorcery purists do not read!

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Mark Andrews <msasgl AT msa-enterprises.com>
  • To: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • Cc: SM-Discuss AT lists.ibiblio.org
  • Subject: Re[2]: [SM-Discuss] sorcery purists do not read!
  • Date: Mon, 9 Dec 2002 15:32:27 +0000

Hello Dufflebunk,

Monday, December 9, 2002, 1:17:50 PM, you wrote:

D> You know, we do always need more bashers for sorcery development...

Yeah, I know.. Most of my ideas seem to be post 1.0 though.. And
non-support of binaries is a show stopper for me. While I'm
conceptually planning on supporting rpm, pkg etc, what I really want
is a way to create a binary distro from within SourceMage. Hence why
my version of summon has a -i [install] option.. cast won't be used on
a binary only system.

Anyway, I figure by doing this now while everyone else is finalising
1.0 gives me a more thorough grounding in linux in general for kicking
in properly on post 1.0 stuff. I just got bored waiting ;-)

>> ML> In fact I think that one feature (very post 1.0) that should be
D> Could someone refresh my memory? What is "that"?

Er.. it's rest of that paragraph.. "depending on specific options"

>> ML> considered, is depending on specific options, somehow (an extreme
>> ML> example could be c++ code depending on the c++ support in gcc,
>> ML> allowing systems without c++ support to be built).

D> Why would you want to use zsh? That's a serious question. I don't know
D> zsh.

A couple of features made it interesting for me.. Compilation of
scripts being one. Smart autoload of functions being another (given a
compiled scribe.zsh and a scribe script, it uses whichever is newer.
Dead handy for having a stable and development version of a script.

The completion features seem more powerful than bash (gaze -[tab] to
get available options listed), but I've not got into that yet. There's
a whole rake of extra commands for dealing with parameters that make
coding simpler. I suspect a lot of what I'm using grep and sed for can
actually be done directly in the shell, but I'm not at the
optimisation stage yet. It also has ftp support built in so it's easy
to provide a cut down summon for inital setup that only requires zsh
and files on an ftp server.. Very optimistically I hope to do an
install floppy!

Plus, in general shell usage it seems more responsive, and it's got
better documentation than bash. But the kicker is that I can type
"zsh" and get my new commands, and "exit" and get the original sorcery
scripts ;-)

Downsides: some would consider it bloated.. default setup isn't really
usable (at least on my box).. still need bash for things like kernel
compilation..

>> Before anyone gets on my back about this, I'm doing it as a learning
>> experience - I've nearly worn out my m, a & n keys. Though a few ideas
>> have come up that would be nice to have in sorcery.
D> Why the HELL are you wasting your time with ... ;) hee hee
D> Dare I ask: "m"?

As in first letter of man.. Actually I've been spending more time in
makefiles and configures recently but that m a n sure comes in handy.

>>
>> Like my ua command which does an extension based (recursive)
>> unarchive command - so things like
>>
>> ua -d /directory file1.tar.gz file2.patch.bz2
>>
>> produce a patched source directory. ua should even handle a
>> patch.tar.Z.gz.bz2 file properly if someone was daft enough to make
>> one. It's extensible to allow extra archive formats to be added
>> (I'm planning rpm & pkg at some point!) - the recursive part just adds
>> piped commands to a TEMPCMD variable to be eval'd at the end of the
>> top layer. The plan is that the bzip2 spell manages it's entry in the
>> ua command and so on..
D> Hmm, interesting.

Yep, probably the coolest bit of code I've done so far. Don't think
it's got any zsh specific stuff in it either so should port easily to
bash. The machines at home at the moment, but I'll bring a copy of
this tomorrow. Basically makes use of ${filename:e} stuff feeding a
case statement, so to add an extra archive format is simply a case of
providing a version of the command that takes standard input,
decompresses and feeds it to standard output. Some are endpoint
commands (patch, tar) which feed directly to the final output file(s).

D> As a side note isn't .Z the same as .gz?

possibly, I did say daft enough... Never said it didn't mean me ;-)

>> I've included versions in the spell names and moved the generic spell
>> name (linux etc) into a variable in the details file and I'm using a
>> flat grimoire. So the above would be from a grimoire/linux-2.4.20 spell.

D> So in order to cast a spell your scripts have to look through all the
D> files in the flat grimoire to find the one with the SPELL=linux (or equiv)
D> line? Or do you always have the first part of the name being the spell?

The spell package is always named with the first part matching the
generic name. So I just check spells beginning with a match for the
actual variable. Multiple matches (linux-2.4.19, linux-2.4.20) are fed
into a select statement to let me choose the specific spell in
interactive mode. I'm planning on using a "locate" database for the
package tree to speed things up where needed.

>> I also seem to be moving away from having build, pre-build etc stuff
>> under specific names.

D> A possible problem with this is you lose stucture. You have more
D> flexibility, but less stucture. Good if you have the self control, but bad
D> if you open it up to everyone to make spells.

The way I'm handling structure is to have checkpoints. So it doesn't
matter (too much) how the spell is formed so long as at the end of say
the extract stage (summon -i) you have a directory in /usr/src called
spell-version that is ready to configure. And so on..

I'm intending scribe to be a helper app here. I've already got a
scribe -n spell-version command to help create new spells. This is a
template driven process where "process_template templatefile
outputfile" scans for %%FIELD%% and uses "read" to get user input to
create the output file. "Enter value for FIELD" type stuff..

D> So long as you're having fun, I don't think anyone will begrudge you your
D> path abuse ;)

I'm sure they won't.. Not until I start wanting to put my ideas into
SourceMage anyway ;-) I really like being able to type "summon -i
spell" and having the source tree for the spell ready to start working
on.. Be better still when "summon -b -i spell" works to install that
binary I compiled last week 8-)

--
Best regards,
Mark mailto:msasgl AT msa-enterprises.com





Archive powered by MHonArc 2.6.24.

Top of Page