dont source procedures for each loaded module. dont auto source core/base either. we now have a dependency system for procedures

4 files changed, 18 insertions, 8 deletions

diff --git a/README b/README
index eb14657..d1a8bef 100644
--- a/README
+++ b/README
@@ -43,8 +43,8 @@ In the code, they are very recognizable and are named like this:
  - worker   -> worker_<baz> ( a worker function, called by a phase. implements some specific logic.
                eg runtime_packages, prepare_disks, package_list etc)
 
-If you specify a procedure name other then base, the base procedure will be sourced first, then the specific
-procedure.  This way you only need to override specific things.
+You can depend on whatever procedure you like (like core/base), to save
+yourself some work (you only need to override a few things)
 
 Notes:
  - The phases are started by the start_process function.  You can also override this function to take flow control in your own hands (eg iterative, menu-based installer)
@@ -71,10 +71,13 @@ Note that if you load a module and a library has the same function names as
 the core module, it will override the functions from core.
 This means you can 'inject' new backend code into core procedures, but you
 can also write your own procedures that use your own, or the core libraries.
-
+If you load a module, you actually load it's libraries, not it's procedures!
+Procedures are only loaded when needed (because you request them because
+of dependencies)
 
 If you need a library from another user contributed module, execute
-'depend_module <modulename>' for each module.
+'depend_module <modulename>' for each module.  This way you load all the
+libs of that module (not the procedures, use depend_procedure for that)
 (very basic dependencies, no version checking etc)
 
 You can specify a core procedure on the command line by specifying
diff --git a/TODO b/TODO
index 0db8651..a3025e6 100644
--- a/TODO
+++ b/TODO
@@ -10,8 +10,9 @@ other steps warning 'not implemented'
   we should have even more flexibilty to take parts from different procedures.
   eg dieter procedure maybe wants to use something interactive. or base
   procedure wants to do something interactive. interactive functions maybe
-  dont belong in a procedure?
-
+  dont belong in a procedure?  -> depend_procedure good enough? or do we
+  need more fine-grained dependencies (take function foo from procedure bar
+  from module baz). for now let's try like this..
 * base procedure idea: it should just tell you what to do? -> less
   implementation work in base procedure, more in other procedures...
 * fix crossconcerns: procedures are about _how_ (autodetection, asking user,...)
diff --git a/dieter/procedures/automatic b/dieter/procedures/automatic
index 2415f99..63fe6c8 100644
--- a/dieter/procedures/automatic
+++ b/dieter/procedures/automatic
@@ -1,5 +1,6 @@
 #!/bin/bash
 var_RUNTIME_PACKAGES="svn"
+depend_procedure core base
 
 phase_preparation ()
 {
diff --git a/src/fifa.sh b/src/fifa.sh
index 1ddf107..38b681f 100755
--- a/src/fifa.sh
+++ b/src/fifa.sh
@@ -86,7 +86,7 @@ load_module ()
 	path=/home/arch/fifa/user/"$1"
 	[ "$1" = core ] && path=/home/arch/fifa/core
 	
-	for submodule in lib procedure
+	for submodule in lib #procedure don't load procedures automatically!
 	do	
 		if [ ! -d "$path/${submodule}s" ]
 		then
@@ -160,6 +160,12 @@ depend_module ()
 }
 
 
+depend_procedure ()
+{
+	load_procedure "$1" "$2"
+}
+
+
 start_process ()
 {
 	execute phase preparation
@@ -194,7 +200,6 @@ fi
 load_module core
 [ "$module" != core -a "$module" != http ] && load_module "$module"
 
-[ "$module" != core -o "$procedure" != base ] && load_procedure core base
 load_procedure "$module" "$procedure"
 
 # Set pacman vars.  allow procedures to have set $var_TARGET_DIR (TODO: look up how delayed variable substitution works. then we can put this at the top again)