Changes between Version 19 and Version 20 of BuildSystem

Timestamp:

Mar 11, 2010, 8:12:09 PM (14 years ago)

Author:

becoulet

Comment:

--

BuildSystem

@@ -237 +237 @@
 == The .config constraints files ==
 
+Their are several types of configuration tokens:
+ * normal features enabling tokens which can be either defined or undefined in build configuration files.
+ * meta tokens which can only get defined through definition of other tokens.
+ * value tokens which can have any value.
+
+=== Token flags ===
+
+Several flags can be attached to tokens, most important ones are:
+ `value`::
+   Indicate the token is a value token. Value tokens can not have dependencies but can take value others than `defined` and `undefined`
+ `meta`::
+   Indicate the token is a meta token which may only be enable by an other token using the `provide` tag.
+ `auto`::
+   Indicate the token should be automatically enabled to satisfy dependencies.
+
+Other flags can be attached to tokens:
+ `harddep`::
+   Indicate the token can not be safely undefined due to a unsatisfied dependency.
+ `mandatory`::
+   Indicate the token can not be undefined. Useful to enforce requirements on other tokens mainly for mandatory modules.
+ `root`::
+   Indicate the token has no parent.
+ `internal`::
+   Indicate the token is for internal use and can not be defined in build configuration file directly
+ `noexport`::
+   Indicate the token should not be written out in generated header file.
+ `private`::
+   Indicate the token can not be used with `parent`, `depend` or `provide` tag from an other `.config` file.
+
+=== Constraint tags ===
+
 For each configuration token, one may use the following tags:
-
  `desc Description string without quotes`::
    Short description about the token
@@ -251 +281 @@
 
 The following tags may be used to specify features constraints:
-
  `depend TOKEN […]`::
    Dependencies, at least one of the feature tokens on the line is required, if unsatisfied the current token gets undefined and a notice is emitted. May be used to disable features because of missing prerequisites.
+ `single TOKEN […]`::
+   Same as depend with the additional constraint that only one of the given tokens is defined
  `exclude TOKEN`::
    Specify excluded token, the current and specified token must not be defined at the same time.
- `single TOKEN […]`::
-   Only one of the following tokens may be defined at the same time
  `when TOKEN_CONDITION […]`::
    The current feature token will be automatically defined if all specified conditions are met.
@@ -264 +293 @@
 
  `require TOKEN_CONDITION […]`::
-   Mandatory requirements, having at least one of the tokens on the line is mandatory, conflict yields error. May be used to enforce definition of some mandatory configuration values.
+   Requirements on value tokens, having at least one condition met on the line is mandatory if the current token is defined.
  `provide TOKEN=value`::
-   Defining the current feature token enforce definition of the specified value token with the given value. The `nodefine` flag indicate token is for internal use and can not be defined by the user.
+   Set a value token to the specified value if the current token is defined.
+ `provide TOKEN`::
+   Define a meta token if the current token is defined.
 
 Some tags can be used to give some configurations advice to the user when building MutekH:
@@ -273 +304 @@
    Defining the current feature token suggest the given condition to the user.
  `suggest_when TOKEN_CONDITION […]`::
-   The current token will suggest being considered to the user if it still has its default value and all condition are met.
+   The current token will suggest being considered to the user if dependencies are actually satisfied all given conditions are met.
 
 The `TOKEN_CONDITION` might check different conditions: