bake-toolkit 2.20.4 → 2.21.0

data/documentation/_build/html/_sources/syntax/adapt_configs.txt

@@ -1,143 +1,143 @@
-Adapt configs
-=============
-
-Introduction
-************
-
-If you want to manipulate existing configs without changing them, you can "adapt" them via command line.
-
-.. code-block:: console
-
-    User@Host:~$ bake test --adapt abc
-
-bake searches for abc/Adapt.meta within the workspace roots. If found, the configs from the adapt file are parsed:
-
-.. code-block:: text
-
-    Adapt {
-      ExecutableConfig ... # 0..n
-      LibraryConfig ... # 0..n
-      CustomConfig ... # 0..n
-    }
-
-Here is an example to change the DefaultToolchain
-
-.. code-block:: text
-
-    Adapt {
-      ExecutableConfig test, project: __MAIN__, type: replace {
-        DefaultToolchain GCC
-      }
-    }
-
-Effectiveness
-*************
-
-The adapt configs can be applied to all configs from regular build. This can be controlled by the config names and the project attributes. The example above
-is adapted only to the config "test" of the main project. __MAIN__ and __ALL__ are keywords. __MAIN__ means the main project or config, __ALL__ means all
-projects or configs. If you want to apply the changes only to the top level config, write:
-
-.. code-block:: text
-
-      ExecutableConfig __MAIN__, project: __MAIN__, ...
-
-If you want to apply the changes to all configs, write:
-
-.. code-block:: text
-
-      ExecutableConfig __ALL__, project: __ALL__, ...
-
-It is possible to mix the keywords with reals project or config names.
-
-Occurrences
-***********
-    
-You can specify more configs in one adapt file and you can specify more than one adapt file:
-
-.. code-block:: text
-
-    Adapt {
-      ExecutableConfig ..., project: ..., type: ... {
-        ...
-      }
-      ExecutableConfig ..., project: ..., type: ... {
-        ...
-      }
-      LibraryConfig ..., project: ..., type: ... {
-        ...
-      }
-      ...
-    }
-
-.. code-block:: console
-
-    User@Host:~$ bake test --adapt abc --adapt xy
-
-They will be applied in the specified order.
-
-Types
-*****
-
-It is possible to specify the type of adaption:
-
-.. code-block:: text
-
-      ExecutableConfig ..., type: replace
-
-The type can be "replace", "remove" or "extend".
-
-Type: extend
-------------
-
-This works exactly like for :doc:`derive_configs`.
-
-Type: remove
-------------
-
-If parent elements can be found which matches to the child elements, they will be removed.
- 
-Example project config:
-
-.. code-block:: text
-
-    ExecutableConfig test {
-      DefaultToolchain GCC
-    }
-
-Example adapt configs:
-
-.. code-block:: text
-
-    ExecutableConfig __ALL__, project: __ALL__, type: remove {
-      DefaultToolchain # remove ok
-    }
-
-    ExecutableConfig __ALL__, project: __ALL__, type: remove {
-      DefaultToolchain GCC # remove ok
-    }
-
-    ExecutableConfig __ALL__, project: __ALL__, type: remove {
-      DefaultToolchain Diab # remove NOT ok
-    }
-
-    ExecutableConfig __ALL__, project: __ALL__, type: remove {
-      DefaultToolchain GCC, eclipseOrder: true # remove NOT ok
-    }
-
-Type: replace
--------------
-
-This is for convenience. "replace" will remove all elements with the same type and extends the configs.
-
-Example:
-
-.. code-block:: text
-
-    ExecutableConfig __ALL__, project: __ALL__, type: replace {
-      Files "*.cpp"
-      DefaultToolchain GCC {
-        Linker command: "link.exe"
-      }
-    }
-
-This removes all "Files" and the "DefaultToolchain" from the original config regardless their attributes and replaces them by the elements of the adapt config.
+Adapt configs
+=============
+
+Introduction
+************
+
+If you want to manipulate existing configs without changing them, you can "adapt" them via command line.
+
+.. code-block:: console
+
+    User@Host:~$ bake test --adapt abc
+
+bake searches for abc/Adapt.meta within the workspace roots. If found, the configs from the adapt file are parsed:
+
+.. code-block:: text
+
+    Adapt {
+      ExecutableConfig ... # 0..n
+      LibraryConfig ... # 0..n
+      CustomConfig ... # 0..n
+    }
+
+Here is an example to change the DefaultToolchain
+
+.. code-block:: text
+
+    Adapt {
+      ExecutableConfig test, project: __MAIN__, type: replace {
+        DefaultToolchain GCC
+      }
+    }
+
+Effectiveness
+*************
+
+The adapt configs can be applied to all configs from regular build. This can be controlled by the config names and the project attributes. The example above
+is adapted only to the config "test" of the main project. __MAIN__ and __ALL__ are keywords. __MAIN__ means the main project or config, __ALL__ means all
+projects or configs. If you want to apply the changes only to the top level config, write:
+
+.. code-block:: text
+
+      ExecutableConfig __MAIN__, project: __MAIN__, ...
+
+If you want to apply the changes to all configs, write:
+
+.. code-block:: text
+
+      ExecutableConfig __ALL__, project: __ALL__, ...
+
+It is possible to mix the keywords with reals project or config names.
+
+Occurrences
+***********
+
+You can specify more configs in one adapt file and you can specify more than one adapt file:
+
+.. code-block:: text
+
+    Adapt {
+      ExecutableConfig ..., project: ..., type: ... {
+        ...
+      }
+      ExecutableConfig ..., project: ..., type: ... {
+        ...
+      }
+      LibraryConfig ..., project: ..., type: ... {
+        ...
+      }
+      ...
+    }
+
+.. code-block:: console
+
+    User@Host:~$ bake test --adapt abc --adapt xy
+
+They will be applied in the specified order.
+
+Types
+*****
+
+It is possible to specify the type of adaption:
+
+.. code-block:: text
+
+      ExecutableConfig ..., type: replace
+
+The type can be "replace", "remove" or "extend".
+
+Type: extend
+------------
+
+This works exactly like for :doc:`derive_configs`.
+
+Type: remove
+------------
+
+If parent elements can be found which matches to the child elements, they will be removed.
+
+Example project config:
+
+.. code-block:: text
+
+    ExecutableConfig test {
+      DefaultToolchain GCC
+    }
+
+Example adapt configs:
+
+.. code-block:: text
+
+    ExecutableConfig __ALL__, project: __ALL__, type: remove {
+      DefaultToolchain # remove ok
+    }
+
+    ExecutableConfig __ALL__, project: __ALL__, type: remove {
+      DefaultToolchain GCC # remove ok
+    }
+
+    ExecutableConfig __ALL__, project: __ALL__, type: remove {
+      DefaultToolchain Diab # remove NOT ok
+    }
+
+    ExecutableConfig __ALL__, project: __ALL__, type: remove {
+      DefaultToolchain GCC, eclipseOrder: true # remove NOT ok
+    }
+
+Type: replace
+-------------
+
+This is for convenience. "replace" will remove all elements with the same type and extends the configs.
+
+Example:
+
+.. code-block:: text
+
+    ExecutableConfig __ALL__, project: __ALL__, type: replace {
+      Files "*.cpp"
+      DefaultToolchain GCC {
+        Linker command: "link.exe"
+      }
+    }
+
+This removes all "Files" and the "DefaultToolchain" from the original config regardless their attributes and replaces them by the elements of the adapt config.

data/documentation/_build/html/_sources/syntax/auto_adjustment.txt

@@ -1,43 +1,43 @@
-Auto-adjustment of paths to existing projects
-=============================================
-
-If paths to other projects are needed, e.g. to "bootloaderUpdater", don't write a hard coded relative path like this:
-
-.. code-block:: text
-
-    CommandLine "../bootloaderUpdater/tools/PrimaryBootloader2Include.exe
-
-If paths to other projects are needed, e.g. to "bootloaderUpdater" just reference it starting from the project folder.
-
-Example:
-
-.. code-block:: text
-
-    CommandLine "bootloaderUpdater/tools/PrimaryBootloader2Include.exe
-
-or:
-
-.. code-block:: text
-
-    IncludeDir "myProjectName/bootloaderUpdater/whatever"
-
-
-
-bake recognizes that the first part of the path is a valid project name and calculates the relative path to the project automatically.
-If you have the special case that the referenced project is contained in an other workspace root, you can use the
-`-w` parameter or you define a `roots.bake`.
-
-.. note::
-
-    The path auto adjustment is applied for the following elements:
-
-    * IncludeDir
-
-    * ExternalLibrary
-
-    * ExternalLibrarySearchPath
-
-    * UserLibrary
-
-    * CommandLine
-
+Auto-adjustment of paths to existing projects
+=============================================
+
+If paths to other projects are needed, e.g. to "bootloaderUpdater", don't write a hard coded relative path like this:
+
+.. code-block:: text
+
+    CommandLine "../bootloaderUpdater/tools/PrimaryBootloader2Include.exe
+
+If paths to other projects are needed, e.g. to "bootloaderUpdater" just reference it starting from the project folder.
+
+Example:
+
+.. code-block:: text
+
+    CommandLine "bootloaderUpdater/tools/PrimaryBootloader2Include.exe
+
+or:
+
+.. code-block:: text
+
+    IncludeDir "myProjectName/bootloaderUpdater/whatever"
+
+
+
+bake recognizes that the first part of the path is a valid project name and calculates the relative path to the project automatically.
+If you have the special case that the referenced project is contained in an other workspace root, you can use the
+`-w` parameter or you define a `roots.bake`.
+
+.. note::
+
+    The path auto adjustment is applied for the following elements:
+
+    * IncludeDir
+
+    * ExternalLibrary
+
+    * ExternalLibrarySearchPath
+
+    * UserLibrary
+
+    * CommandLine
+

data/documentation/_build/html/_sources/syntax/derive_configs.txt

@@ -1,94 +1,93 @@
-Derive configs
-==============
-
-bake supports deriving configs, which allows you to put repetetive settings in a base config.
-
-Deriving a config
-*****************
-
-Derving a config in bake is pretty straight forward, and looks like this:
-
-.. code-block:: text
-
-    ExecutableConfig A
-    LibraryConfig    B, extends: A
-    CustomConfig     C, extends: B
-    ExecutableConfig D, extends: C
-
-.. note::
-
-    The config type of the parent config does not matter, but only settings which are valid in BOTH configs will be inherited.
-    In the example above D gets the dependencies from A, because "Dependency" is valid in all configs, but D does not get 
-    the "Files" from A and B, because "Files" is not valid in CustomConfig.
-
-
-Inheritance implications
-************************
-
-In general it is very easy.
-
-- Elements which can exist more than once (e.g. "Files"), are simply concatenated. First the parent elements, then the client elements.
-- Elements which can exist only once:
- 
-  - if it exists in EITHER child OR parent, use this one
-  - is it exists in BOTH, attributes are merged (child attributes have high priority) and sub elements are inherited recursively
-
-The following example
-
-.. code-block:: text
-
-    ExecutableConfig A {
-      Files "x.cpp"
-      Files "y.cpp"
-      ArtifactName "z.exe"
-      DefaultToolchain GCC {
-        Linker {
-          Flags "-O3"
-        }
-      }
-    }
-    ExecutableConfig B, extends: A {
-      Files "z.cpp"
-      IncludeDir "inc"
-      ArtifactName "a.exe"
-      DefaultToolchain Diab {
-        Compiler CPP {
-          Define "TEST"
-        }
-      }
-    }
-    
-results implicitly in:
-
-.. code-block:: text
-
-    ExecutableConfig B {
-      Files "x.cpp"
-      Files "y.cpp"
-      Files "z.cpp"
-      IncludeDir "inc"
-      ArtifactName "a.exe"
-      DefaultToolchain Diab {
-        Compiler CPP {
-          Define "TEST"
-        }
-        Linker {
-          Flags "-O3"
-        }
-      }
-    }
-    
-
-Multiple inheritance
-********************
-
-It is possible to derive from several projects:
-
-.. code-block:: text
-
-    ExecutableConfig A
-    LibraryConfig    B
-    ExecutableConfig C, extends: "A, B"
-    
-"extends" defines a comma separated list. The merge will be performed with all parent configs.
- 
+Derive configs
+==============
+
+bake supports deriving configs, which allows you to put repetetive settings in a base config.
+
+Deriving a config
+*****************
+
+Derving a config in bake is pretty straight forward, and looks like this:
+
+.. code-block:: text
+
+    ExecutableConfig A
+    LibraryConfig    B, extends: A
+    CustomConfig     C, extends: B
+    ExecutableConfig D, extends: C
+
+.. note::
+
+    The config type of the parent config does not matter, but only settings which are valid in BOTH configs will be inherited.
+    In the example above D gets the dependencies from A, because "Dependency" is valid in all configs, but D does not get
+    the "Files" from A and B, because "Files" is not valid in CustomConfig.
+
+
+Inheritance implications
+************************
+
+In general it is very easy.
+
+- Elements which can exist more than once (e.g. "Files"), are simply concatenated. First the parent elements, then the client elements.
+- Elements which can exist only once:
+
+  - if it exists in EITHER child OR parent, use this one
+  - is it exists in BOTH, attributes are merged (child attributes have high priority) and sub elements are inherited recursively
+
+The following example
+
+.. code-block:: text
+
+    ExecutableConfig A {
+      Files "x.cpp"
+      Files "y.cpp"
+      ArtifactName "z.exe"
+      DefaultToolchain GCC {
+        Linker {
+          Flags "-O3"
+        }
+      }
+    }
+    ExecutableConfig B, extends: A {
+      Files "z.cpp"
+      IncludeDir "inc"
+      ArtifactName "a.exe"
+      DefaultToolchain Diab {
+        Compiler CPP {
+          Define "TEST"
+        }
+      }
+    }
+
+results implicitly in:
+
+.. code-block:: text
+
+    ExecutableConfig B {
+      Files "x.cpp"
+      Files "y.cpp"
+      Files "z.cpp"
+      IncludeDir "inc"
+      ArtifactName "a.exe"
+      DefaultToolchain Diab {
+        Compiler CPP {
+          Define "TEST"
+        }
+        Linker {
+          Flags "-O3"
+        }
+      }
+    }
+
+
+Multiple inheritance
+********************
+
+It is possible to derive from several projects:
+
+.. code-block:: text
+
+    ExecutableConfig A
+    LibraryConfig    B
+    ExecutableConfig C, extends: "A, B"
+
+"extends" defines a comma separated list. The merge will be performed with all parent configs.