Skip to Content.
Sympa Menu

sm-discuss - [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: Mads Laursen <dossen+sgl AT daimi.au.dk>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] sorcery purists do not read!
  • Date: Mon, 9 Dec 2002 12:38:00 +0000

Hello Mads,

Wednesday, December 4, 2002, 10:42:32 PM, you wrote:

ML> In fact I think that one feature (very post 1.0) that should be
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).

This is something that is pretty much a prerequiste for handling
automatic hardware configuration properly. And something that I've
been pondering how to handle best for some time. I've mentioned before
about possibly needing hardware spells and these obviously need to
depend on options to be handled cleanly. Think of a USB device that
may well depend on it's own driver, the hotplug stuff plus a kernel
compiled with USB support and you'll see where I'm going with this.

ML> Anyway, I'll stop before I get too far of track.

Doubt you'll get as far me. I'm currently working through Linux from
Scratch creating my own versions of summon, gaze, scribe and a
grimoire as I go. And I'm using zsh not bash...

I'm working on providing full dependancies, including config options
where appropriate (particularly useful for handling binaries as well),
and full tracking including extract, configure, build and install
stages.

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.

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

I've also seperated the source file information from details into
seperate '.info' files. This allows for things like:

if [[ -e ${FILECACHE}/linux-2.4.19.tar.gz ]]; then
store ${SPELLDIR}/src/linux-2.4.20.tar.gz.info SKIPFILE 1
store ${SPELLDIR}/src/linux-2.4.19.tar.gz.info SKIPFILE 0
store ${SPELLDIR}/src/patch-2.4.19-2.4.20.patch.bz2.info" SKIPFILE 0
else
store ${SPELLDIR}/src/linux-2.4.20.tar.gz.info SKIPFILE 0
store ${SPELLDIR}/src/linux-2.4.19.tar.gz.info SKIPFILE 1
store ${SPELLDIR}/src/patch-2.4.19-2.4.20.patch.bz2.info SKIPFILE 1
fi

And during the download processing a SKIPFILE=1 setting causes the
file to be skipped. I've also moved the md5sum into these info files
along with the download location. I'm checking the download md5sum
rather than the extracted one. As far as I'm concerned if it ain't
a valid archive then I don't want to waste any more CPU on it ;-)

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.

Mirror handling I've moved out of spells completely. The spell
specifies the authorative location and the url is processed against a
mirror list which can swap the first part of the url out when
required. So a GNU-mirrors file would have ftp://ftp.gnu.org/pub/gnu/
plus the equivalent path section for the mirrors listed. Well that's
the plan.. My current alternative summon just uses cached files 8-(

I also seem to be moving away from having build, pre-build etc stuff
under specific names. The names of .info & .action files is
independant of the actual filenames (to allow sys-v style filename
based ordering to apply patches at the right time) so it's actually
very easy to do spells with configure and build scripts at the
appropriate points (.action files I'm calling them currently). I'm
thinking of adding a STAGE= field to all these scripts to allow
selective actions.

So .info files would be STAGE=download:extract (or
STAGE=download:install for binaries), build files STAGE=compile,
STAGE=download for the SKIPFILE configuration script above (with a
00skipfiles.action filename) and so on.

A simple $(grep -H "STAGE=.*extract" ${SPELLDIR}/src/*) then gives a
complete ordered list of scripts to 'run' to create the build directory.
$(ls ${SPELLDIR}/src/*) gives the list to do everything - download,
extract, configure, build, install.. 'run' sometimes means just that
(.action), others (.info files) it means process the data in the file
using a particular routine.

But back to the original point.. One of these data scripts (.depend)
will support providing the compile options required for a dependancy.
I'm thinking one spellname.depend file per dependancy so variables to
control version specific depends, config depends etc go into that
file. So a hardware spell may just be a .depend for specific kernel
options.

And you thought you were off the beaten track?! <big grin>

If anyone's wondering, I'm about halfway through the static stage of
LFS at the moment with auto extraction but manual builds. I'm going to
add auto builds in at the dynamic stage when I'm a bit clearer on just
what is needed by the various configure & build methods.

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





Archive powered by MHonArc 2.6.24.

Top of Page