Changes between Version 8 and Version 9 of BuildSystemDev

Timestamp:

Oct 11, 2012, 4:19:51 PM (12 years ago)

Author:

becoulet

Comment:

--

BuildSystemDev

@@ -137 +137 @@
 
 Initialization order of different software components at system start needs close attention.
-Having all modules and features initialized in proper order is challenging in modular and configurable projects like MutekH.
-
-The configuration tools offers a way to specify initialization code ordering constraints and to optionally associate them to configuration tokens.
+Having all modules and features initialized in proper order is challenging in a modular and configurable project like MutekH.
+
+The configuration tool offers a way to specify initialization code ordering constraints and to optionally associate them to configuration tokens.
 This has several advantages:
  * It allows inserting external modules initialization code in the right place without patching the main tree.
  * It avoids the burdensome work of maintaining initialization function calls and associated `#ifdef` directives.
- * It ensures initialization function invocations do not get badly reordered to satisfy a new constraint, while ignoring an older one.
+ * It ensures initialization function invocations do not get badly reordered to satisfy a new constraint, while ignoring an older constraint.
 
 Initialization tokens can be declared for that purpose, each specifying a different stage in the MutekH initialization process.
-These tokens live in a separate name space from configuration tokens and are not exported in configuration output.
-
-A C source file will be automatically generated with initialization code from active tokens, respecting ordering constraints and current configuration.
+These tokens live in a separate name space from configuration tokens and are not exported in the configuration output.
+Instead a set of function prototypes and properly ordered function calls code are written as C macros which can then be invoked at the right place in the kernel code.
 An error will be emitted if constraints can not be satisfied.
 
@@ -161 +160 @@
    This tag imposes the requirement that the code from current token be executed '''before''' the code associated with INIT_TOKEN.
  `during INIT_TOKEN`::
-   This tag makes the current token inherits from constraints expressed for the given INIT_TOKEN. The given token must be a place holder token and can not have associated code.
- `code C code here`::
-   This tag associates some initialization C code to the token. This tag may be used multiple times to add more code lines.
+   This tag makes the current token inherits from constraints expressed for the given INIT_TOKEN. This token must be a place holder token and can not have associated functions.
+ `functions init_function_name cleanup_function_name`::
+   This tag associates some initialization and cleanup C function names to the token. The cleanup function is optional.
+ `prototype type arg0, type *arg1`::
+   This tag sets a list of arguments used in init and cleanup functions prototypes. It must be used on the root place holder tokens so that the prototype is valid for all functions of children tokens.
 
 === Example ===
@@ -179 +180 @@
   during INIT_LIBRARIES
   after INIT_LIBC_STDIO      # an explanation why this is needed
-  code great_feature_init();
+  functions great_feature_init great_feature_cleanup
 %init end
+}}}
+
+This will generate the following macros for use in MutekH source code, provided that the CONFIG_FEATURE token is defined in build configuration:
+
+{{{
+#define INIT_LIBRARIES_PROTOTYPES \
+  void great_feature_init(); \
+  void great_feature_cleanup();
+
+#define INIT_LIBRARIES_INIT(...) \
+  great_feature_init(__VA_ARGS__); \
+
+#define INIT_LIBRARIES_CLEANUP(...) \
+  great_feature_claenup(__VA_ARGS__); \
 }}}