Skip to Content.
Sympa Menu

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

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] grimoire API and splitting BUILD
  • Date: Wed, 31 Mar 2004 11:43:05 -0800

Quoting Andrew <afrayedknot AT thefrayedknot.armory.com>:
> 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)

The 'sorcery' user, yes?

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

Why have to scripts run after INSTALL? couldn't we rename both POST_BUILD and
POST_INSTALL to FINAL (or just merged into POST_INSTALL)?

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

Sounds good. Is this /just/ for the transition period, or a permanent
addition?

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

Easy is good, especially when it's making it so we can do things in baby
steps.

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

For now would it be possible to use the simple API_VERSION and then at a later
date, if needed, extend it to support each script?

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

I like this idea in general (homogonized spells), but am leary of having
sections overriding Sorcery functions, as this can lead to a mess down the
road.

> 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

Thanks for the summarization. ;)

-sandalle

--
PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o?
K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++)
tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+
------END GEEK CODE BLOCK------

Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




Archive powered by MHonArc 2.6.24.

Top of Page