Changes between Version 21 and Version 22 of BuildSystem

Timestamp:

Mar 12, 2010, 3:48:59 AM (14 years ago)

Author:

becoulet

Comment:

--

BuildSystem

@@ -246 +246 @@
 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`
+   Indicate the token is a value token. Value tokens can not have dependencies but can take values other 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.
+   Indicate the token is a meta token which may only be defined by an other token using the `provide` tag.
  `auto`::
    Indicate the token should be automatically enabled to satisfy dependencies.
@@ -256 +256 @@
    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.
+   Indicate the token can not be undefined at all. 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
+   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.
+   Indicate the token should not be written out in generated files.
  `private`::
    Indicate the token can not be used with `parent`, `depend` or `provide` tag from an other `.config` file.
@@ -270 +270 @@
 For each configuration token, one may use the following tags:
  `desc Description string without quotes`::
-   Short description about the token
+   Short description about the token, multiple `desc` tags will be concatenated.
  `flags FLAGS […]`
-   Set some flags with special meaning for the token.
+   Set some flags with special meaning for the token (see above).
  `parent TOKEN`::
-   Hierarchical dependency, it ensures all token with a parent gets silently undefined if the parent is undefined. This prevents options enabled by default to stay enabled if the parent is disabled; this way it avoids errors due to unneeded requirements. This is also used to hide irrelevant tokens from the help screen if the parent token is undefined. Tokens with no parent must have the `root` flag set or use the `module` tag.
+   Hierarchical dependency, it ensures all token with a parent gets silently undefined if the parent is undefined. This prevents options enabled by default to stay enabled if the parent is disabled; this way it avoids errors due to unneeded requirements. This is also used to hide irrelevant tokens from the help screen if the parent token is undefined.
  `default value`::
    Set the token default value. `defined` and `undefined` values act as booleans. default value is `undefined` if this line is omitted.
@@ -282 +282 @@
 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.
+   The tag must be used to express feature dependencies, at least one of the given feature tokens is required. Unsatisfied dependency undefine the current token and emit a notice, unless flags modify this behavior.
  `single TOKEN […]`::
-   Same as depend with the additional constraint that only one of the given tokens is defined
+   Same as depend with the additional constraint that only one of the given tokens may be defined.
  `exclude TOKEN`::
-   Specify excluded token, the current and specified token must not be defined at the same time.
+   Specify excluded tokens, the current token must not be defined at the same time as any given token.
  `when TOKEN_CONDITION […]`::
-   The current feature token will be automatically defined if all specified conditions are met.
+   The current feature token will be automatically defined if all specified conditions are met. Missing dependencies will emit a notice as if it was defined in the build configuration file.
  `provide TOKEN`::
    Define a meta token if the current token is defined.
@@ -295 +295 @@
 
  `require TOKEN_CONDITION […]`::
-   Requirements on value tokens, having at least one condition met on the line is mandatory if the current token is defined.
+   Requirements on value tokens, having at least one condition evaluates to true on the line is mandatory if the current token is defined.
  `provide TOKEN=value`::
    Set a value token to the specified value if the current token is defined.
@@ -304 +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 dependencies are actually satisfied all given conditions are met.
+   The current token will be suggested to the user if dependencies are actually satisfied and all given conditions are met.
 
 The `TOKEN_CONDITION` might check different conditions:
@@ -312 +312 @@
  * Token numerical value magnitude check: `TOKEN<value` or `TOKEN>value`
 
-The configuration tool will check all rules when building MutekH with a given build configuration file.
-
-Example:
+The configuration tool will check both constraint rules consistency and build configuration file respect of the rules when building MutekH.
+
+Configuration constraints example:
 {{{
 %config CONFIG_FEATURE