Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] grimoire API and splitting BUILD

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: [SM-Discuss] grimoire API and splitting BUILD
  • Date: Wed, 31 Mar 2004 10:55:52 -0800


With the upcoming gnome 2.6 spells hitting the grimoire we decided that
splitting up BUILD and adjusting some files in the grimoire would follow.

We also seemed to have come to the conclusion that having a defined api,
and having each grimoire specify what api it was written for. During
this process of splitting BUILD test/devel grimoires will be used as
the testing ground, whilst stable will continue to have use the old style.
So the need for sorcery to speak both is quite important. (enough said)

I think that we need to create three specifications, the first being
the old grimoire spec, which we mostly already have on the wiki. A
new grimoire spec with the BUILD split and POST_INSTALL/POST_BUILD
adjustments, along with adjustments to libapi calls. Finally we need
something to specify which grimoire api we are on.

Here are some rough drafts:
New grimoire api file changes
BUILD is split into three parts
COMPILE, PRE_INSTALL, and INSTALL

* COMPILE the actual act of compiling the software, should not
require a priveledged user. (ie ./configure; make)

* PRE_INSTALL, this step requires priveledges and invloves removing the
files previously installed by this spell. (prepare_install)

* INSTALL, also requires priveledges, does the make install phase, and
anything
installwatch will track any files this phase installs.

* PRE_BUILD will be known as PRE_COMPILE and runs before COMPILE as usual
* POST_BUILD will be known as POST_INSTALL, and will run after INSTALL
* POST_INSTALL will be known as FINAL and is run after POST_INSTALL
(formerly POST_BUILD)

New grimoire libapi changes:
the default_build function is going to be split into default_compile
default_pre_install and defalt_install. Likewise the default_post_build
and default_post_install become default_post_install and default_final
respectively.

Amendments? Comments? This is your api, now is the time to remove any
deficiencies.

Now for specifying which api we are using:
I propose that every grimoire have a file known as
API_VERSION in it.
This file will be a bash sourceable script and for now look like this:
GRIMOIRE_VERSION=1
We should enumerate each griomire api we make (allowing room for
improvments down the road). The one we are using now will be numbered
'1' the new one will be '2'. Ideally we can just perform a switch in
cast to run the right code. If the file is missing, version 1 will be
the default (for now at least).

I also propose that the API_VERSION file be optional at the section and
spell level. The spell level taking precidence over the section
and section over the griomire version. This allows the transition to be
smoother and can allow more flexibility down the road.

Another idea that I just had was to actually have several different
versions for different parts of the cast process. Spells are
really divided into three pieces: the setup (PREPARE/DETAILS
(sort of)/CONFIGURE/DEPENDS), the building/installing
(PRE_BUILD/COMPILE/PRE_INSTALL/INSTALL/POST_INSTALL/FINAL) and the
removing (PRE_REMOVE/POST_REMOVE). So perhaps an api version for each
would be helpful. The changes Im discussing only involve the build/install
phase, but future work might enhance other aspects. (maybe im going
overboard). The reasoning behind this is that we may be casting spells
that use different api versions, and the part of cast where we do
dependency questions and the part where we do the building/installing
are completely seperate (different processes even).

There are some other possibilities where we can go with this API_VERSION
stuff, including putting specialized code in that file to override certain
sorcery functions, for example if a section (like php-pear or perl-cpan)
is made of mostly homogenous spells all needing a common COMPILE file,
we can just override the default_compile function (just a thought).

Anyways, I think I've opened up enough cans of worms for one morning.
Obviously some of these ideas should stay ideas for now and shouldn't
implement right away.

Plesae feel free to make ammendments to the API_VERSION specification
and the new grimoire specification. At some point it will get wiki'ized,
probably around the time that this thread ends.

-Andrew




Archive powered by MHonArc 2.6.24.

Top of Page