Discussion of Sorcery related topics

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

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

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

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

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

-Andrew

-- 
________________________________________________________________________
|Andrew D. Stitt                             | astitt AT sourcemage.org    |
|irc: afrayedknot                            | afrayedknot AT t.armory.com |
|aim: thefrayedknot or iteratorplusplus      |                          |
|Grimoire Guru ham/smgl, Porting Team Lead   | ftp://t.armory.com       |
|Author and Maintainer of Prometheus         |                          |
-------------------------------------------------------------------------