Skip to Content.
Sympa Menu

sm-sorcery - Re: [SM-Sorcery] splitting BUILD

sm-sorcery AT lists.ibiblio.org

Subject: Discussion of Sorcery related topics

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-sorcery AT lists.ibiblio.org
  • Subject: Re: [SM-Sorcery] splitting BUILD
  • Date: Sun, 14 Mar 2004 12:50:39 +0100

On Sat, Mar 13, 2004 at 10:03:56AM -0800, Andrew wrote:
> >
> > I agree that it should be renamed, the overhead isn't very big (i
> > renamed the WEBSERVER provides to APACHE some days ago, it's easy to do
> > such changes with a nice script :)
> > The names POST_INSTALL and FINAL as described above sound good to me.
> The only problem I have with POST_BUILD -> POST_INSTALL is it isn't
> backwards compatible and so the change must be atomic. Its really of
> no concern so long as everyone is on the latest sorcery before casting
> something from the fully updated grimoire, but 'bad things' may be
> more likely.

Maybe we could introduce something like a sorcery/grimoire API version.
A file in the grimoire root directory API_VERSION containing a version
string, and sorcery checking that version before casting something from
the grimoire and aborting when it's the wrong version.

> >
> > Before starting such a big change though, we'd need to have the relevant
> > code in sorcery very well tested and then put into stable. This should
> > also be postponed until gnome2 final is done, because devel grimoire
> > will be a testing ground for the gnome2 beta for the next week.
> Im not sure I follow why gnome2 final has anything to do with this.

What it has to do with this is that there won't be a global rename
POST_BUILD -> POST_INSTALL, POST_INSTALL -> FINAL until the big gnome
change made it into test. One big change at a time in devel is enough
imo.

> > So, time enough to think this through and test it extensively :)
> If you're using devel sorcery at least part of the new logic is being
> exercised. I can change the logic a bit more for the time being to run
> the defualt install/compiles if no BUILD exists, which would then test
> the rest of the code. Although the only changes that were required were
> moving code around and adding that little if statement to cast_spells.
>
> >
> > I got some questions/suggestions about the COMPILE/INSTALL design:
> > - sorcery should run prepare_install automatically before calling
> > INSTALL (i'm not sure if you meant that, but i couldn't find it
> > explicitly mentioned in the wiki page
> As it stands now prepare_install is run in INSTALL, another logical
> enhancement is to make a POST_COMPILE or PRE_INSTALL file that by default
> runs it, so if the spell has to do something special it can. Adding that
> would be 'nearly trivial' at this point. I can even update my automagic
> build splitting script to make INSTALL w/o prepare_install.
>
> > - "run_compile and run_install should consist of logically split
> > portions of run_build. An enhancement thereof would be to take the
> > code that deals with ./configure out of that run_build (as it will have
> > to be duplicated) and place it in a seperate function."
> > What do you mean with "as it will have to be duplicated"?
> I am refering to the code that relates to the CONFIG_LOC setting, ie:
> "Do you wish to add -- options to ./configure?"
> When I replicated run_build as two seperate functions (run_compile
> and run_install), the code for the aformentioned feature was in both
> run_compile and run_build, of course, so I pulled it out of both and
> replaced it by a call to 'run_config_loc' which is the new home for that
> code. That way code reproductions is slightly smaller.

Ok, that makes sense, thanks for the clarification :)

> > Do you plan
> > to run configure again in INSTALL? I can assure you this will break
> > with several hundreds of programs, due to the many buggy automake
> > setups used by software authors.
> I do not plan on re-running configure in INSTALL, Im sorry for being
> ambiguous. COMPILE is everything before prepare_install and INSTALL
> is everything including and after prepare_install (although subject
> aforementioned changes).

--
Arwed v. Merkatz Sourcemage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page