sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: dufflebunk AT thefrayedknot.armory.com
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] grimoire API and splitting BUILD
- Date: Wed, 31 Mar 2004 11:49:22 -0800
In the specs, we must make sure we specify which spell components are
used in cast, dispel and resurrecting. There are frequently questions on
what parts are use in a resurrect. I assume COMPILE and INSTALL won't
be, but the others may be.
On Wed, Mar 31, 2004 at 10:55:52AM -0800, Andrew wrote:
>
> 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
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
-
[SM-Discuss] grimoire API and splitting BUILD,
Andrew, 03/31/2004
-
Re: [SM-Discuss] grimoire API and splitting BUILD,
Eric Sandall, 03/31/2004
- Re: [SM-Discuss] grimoire API and splitting BUILD, Andrew, 03/31/2004
-
Re: [SM-Discuss] grimoire API and splitting BUILD,
dufflebunk, 03/31/2004
- Re: [SM-Discuss] grimoire API and splitting BUILD, Andrew, 03/31/2004
-
Re: [SM-Discuss] grimoire API and splitting BUILD,
Robert Helgesson, 03/31/2004
- Re: [SM-Discuss] grimoire API and splitting BUILD, Andrew, 03/31/2004
- Re: [SM-Discuss] grimoire API and splitting BUILD, Hamish Greig, 03/31/2004
- Re: [SM-Discuss] grimoire API and splitting BUILD, Jason Flatt, 03/31/2004
-
Re: [SM-Discuss] grimoire API and splitting BUILD,
Eric Sandall, 03/31/2004
Archive powered by MHonArc 2.6.24.