bake-toolkit 2.20.4 → 2.21.0

data/documentation/_build/html/_sources/commandline/commandline.txt

@@ -1,107 +1,107 @@
-Commandline
-===========
-
-How to get help
-***************
-
-.. code-block:: console
-
-    User@Host:~$ bake -h
-    
-The most important options
-**************************
-
-#. *-b* the build configuration name
-
-#. *-m* the main project directory (default is current directory)
-
-#. *-p* the project to build (if not specified, the main project will be built with all dependencies) 
-
-   .. note::
-    
-        All configs of the project will be built, which is usually just one config, but if you have more than one config of the project in the workspace, use a comma separator.
-
-Examples
-********
-
-Building an application
------------------------
-
-    .. code-block:: console
-
-        User@Host:~$ bake -b Debug
-
-    .. note::
-
-        It is possible to omit *-b*:
-
-        .. code-block:: console
-
-            User@Host:~$ bake Debug
-
-Building from within an arbitrary directory
--------------------------------------------
-
-    .. code-block:: console
-
-        User@Host:~$ bake Debug -m w:/root/mainProj
-
-Building just one specific project
------------------------------------
-Assuming the project name to build s myProj.
-
-    .. code-block:: console
-
-        User@Host:~$ bake Debug -m w:/root1/myProj -p myProj
-
-Building specific projects with differnt roots
-----------------------------------------------
-Assuming mainProj has several configs really included in the build (which is uncommon), you can choose one of the configs.
-
-
-    .. code-block:: console
-
-        User@Host:~$ bake Debug -m w:/root1/myProj -p myProj,abc
-
-
-Building a project which has more than one root
------------------------------------------------
-Assuming code has been checked out into two roots, the console supports ansi colors, you want to stop on first error and build only the project bspAbc.
-   
-    .. code-block:: console
-
-        User@Host:~$ bake Debug -m w:/root1/myProj -w w:/root1 -w w:/root2 -r -a black -p bspAbc
-
-
-Clean a project(s)
-------------------
-
-    .. code-block:: console
-
-        User@Host:~$ bake Debug -m w:/root1/myProj -w w:/root1 -w w:/root2 -r -a black -p bspAbc -c
-
-Build a single file(s)
-----------------------
-    .. code-block:: console
-
-        User@Host:~$ bake Debug -p bspAbc -f main.cpp
-        User@Host:~$ bake Debug -f .asm
-
-    .. note::
-
-        All files matching the pattern will be compiled (no wildcards allowed)
-
-
-roots.bake
-**********
-
-Workspace roots can be defined in a file called "roots.bake", which will be searched from main project directory to root folder.
-Example:
-
-    .. code-block:: console
-	
-        ../..
-        C:/another/root # comments written like this
-        something/else
-	
-If -w and roots.bake are not specified, the default workspace root is the parent directory of the main project.
+Commandline
+===========
+
+How to get help
+***************
+
+.. code-block:: console
+
+    User@Host:~$ bake -h
+
+The most important options
+**************************
+
+#. *-b* the build configuration name
+
+#. *-m* the main project directory (default is current directory)
+
+#. *-p* the project to build (if not specified, the main project will be built with all dependencies)
+
+   .. note::
+
+        All configs of the project will be built, which is usually just one config, but if you have more than one config of the project in the workspace, use a comma separator.
+
+Examples
+********
+
+Building an application
+-----------------------
+
+    .. code-block:: console
+
+        User@Host:~$ bake -b Debug
+
+    .. note::
+
+        It is possible to omit *-b*:
+
+        .. code-block:: console
+
+            User@Host:~$ bake Debug
+
+Building from within an arbitrary directory
+-------------------------------------------
+
+    .. code-block:: console
+
+        User@Host:~$ bake Debug -m w:/root/mainProj
+
+Building just one specific project
+-----------------------------------
+Assuming the project name to build s myProj.
+
+    .. code-block:: console
+
+        User@Host:~$ bake Debug -m w:/root1/myProj -p myProj
+
+Building specific projects with differnt roots
+----------------------------------------------
+Assuming mainProj has several configs really included in the build (which is uncommon), you can choose one of the configs.
+
+
+    .. code-block:: console
+
+        User@Host:~$ bake Debug -m w:/root1/myProj -p myProj,abc
+
+
+Building a project which has more than one root
+-----------------------------------------------
+Assuming code has been checked out into two roots, the console supports ansi colors, you want to stop on first error and build only the project bspAbc.
+
+    .. code-block:: console
+
+        User@Host:~$ bake Debug -m w:/root1/myProj -w w:/root1 -w w:/root2 -r -a black -p bspAbc
+
+
+Clean a project(s)
+------------------
+
+    .. code-block:: console
+
+        User@Host:~$ bake Debug -m w:/root1/myProj -w w:/root1 -w w:/root2 -r -a black -p bspAbc -c
+
+Build a single file(s)
+----------------------
+    .. code-block:: console
+
+        User@Host:~$ bake Debug -p bspAbc -f main.cpp
+        User@Host:~$ bake Debug -f .asm
+
+    .. note::
+
+        All files matching the pattern will be compiled (no wildcards allowed)
+
+
+roots.bake
+**********
+
+Workspace roots can be defined in a file called "roots.bake", which will be searched from main project directory to root folder.
+Example:
+
+    .. code-block:: console
+
+        ../..
+        C:/another/root # comments written like this
+        something/else
+
+If -w and roots.bake are not specified, the default workspace root is the parent directory of the main project.

data/documentation/_build/html/_sources/concepts/build_hierarchy.txt

@@ -1,34 +1,34 @@
-The build hierarchy
-===================
-
-Build graph
-***********
-
-Depending on the contents of the Project.meta files, a build graph will be generated:
-    * An ExecutableConfig usually specifies files to compile, dependencies to other projects and linker stuff.
-    * A LibraryConfig usually specifies files to compile and archive.
-    * A CustomConfig usually defines a custom step.
-
-Every config type can be equipped with pre and post steps like shell commands or makefiles.
-
-All these steps will be combined to a build graph.
-
-Example
-*******
-
-The main project has dependencies to the projects A, B and C:
-
-    .. image:: ../_static/bake_build_hierachy.png
-        :width: 100 %
-        :scale: 75 %
-
-Steps are executed bottom-up. If one step fails, all steps above won't be executed.
-
-If e.g.
-    * PreStepMain 2 fails
-    * at least one file of library B does not compile
-then
-    * library B will not be created
-    * files of the main project will not be compiled
-    * main project will not be linked
-    * post step of main project will not be executed
+The build hierarchy
+===================
+
+Build graph
+***********
+
+Depending on the contents of the Project.meta files, a build graph will be generated:
+    * An ExecutableConfig usually specifies files to compile, dependencies to other projects and linker stuff.
+    * A LibraryConfig usually specifies files to compile and archive.
+    * A CustomConfig usually defines a custom step.
+
+Every config type can be equipped with pre and post steps like shell commands or makefiles.
+
+All these steps will be combined to a build graph.
+
+Example
+*******
+
+The main project has dependencies to the projects A, B and C:
+
+    .. image:: ../_static/bake_build_hierachy.png
+        :width: 100 %
+        :scale: 75 %
+
+Steps are executed bottom-up. If one step fails, all steps above won't be executed.
+
+If e.g.
+    * PreStepMain 2 fails
+    * at least one file of library B does not compile
+then
+    * library B will not be created
+    * files of the main project will not be compiled
+    * main project will not be linked
+    * post step of main project will not be executed

data/documentation/_build/html/_sources/concepts/concepts.txt

@@ -1,14 +1,14 @@
-Concepts
-==========
-
-.. toctree::
-    :maxdepth: 2
-
-
-    the_project_meta_file
-    the_main_project
-    build_hierarchy
-    link_order
-    prebuild
-    inject
-
+Concepts
+==========
+
+.. toctree::
+    :maxdepth: 2
+
+
+    the_project_meta_file
+    the_main_project
+    build_hierarchy
+    link_order
+    prebuild
+    inject
+

data/documentation/_build/html/_sources/concepts/inject.txt

@@ -1,65 +1,65 @@
-Injection and inheritance of IncludeDir and Dependency
-******************************************************
-
-It is possible to inject and inherit "includes" and inject "dependencies".
-
-Inherit IncludeDir
-==================
-
-.. code-block:: console
-
-    IncludeDir include, inherit: true
-
-This is typically used to make include directories available to upper levels, e.g.:
-
-
-.. code-block:: console
-
-    # in MyLib/Project.meta
-    LibraryConfig Lib {
-      ...
-      IncludeDir include, inherit: true
-    }
-
-    # in main/Project.meta
-    ExecutableConfig Debug {
-      ...
-      Dependency MyLib, config: Lib
-      # IncludeDir "MyLib/include" - not needed because this IncludeDir is inherited
-    }
-
-Inject IncludeDir
-=================
-
-.. code-block:: console
-
-    IncludeDir "mock/include", inject: front
-
-"front" is used for mocking IncludeDirs, e.g. if a library shall include a mocked class instead of the original one in UnitTest context.
-
-.. code-block:: console
-
-    IncludeDir include, inject: back
-
-"back" is used if the lower levels do not know by themselves what to include. So this has to be configured from the outside, typically in the main project.
-
-Inject Dependency
-=================
-
-.. code-block:: console
-
-    Dependency MyLib, inject: front # or back
-
-This is used if a component cannot have this dependency hard coded, because it shall not know the concrete implementation or the dependency is only used for unittesting.
-
-Example:
-
-.. code-block:: console
-
-    ExecutableConfig UnitTest {
-      ...
-      Dependency config: Lib
-      Dependency googleTest, inject: front
-    }
-
-In this example the config Lib depends on googleTest. If googleTest inherits an IncludeDir, this would be known by Lib.
+Injection and inheritance of IncludeDir and Dependency
+******************************************************
+
+It is possible to inject and inherit "includes" and inject "dependencies".
+
+Inherit IncludeDir
+==================
+
+.. code-block:: console
+
+    IncludeDir include, inherit: true
+
+This is typically used to make include directories available to upper levels, e.g.:
+
+
+.. code-block:: console
+
+    # in MyLib/Project.meta
+    LibraryConfig Lib {
+      ...
+      IncludeDir include, inherit: true
+    }
+
+    # in main/Project.meta
+    ExecutableConfig Debug {
+      ...
+      Dependency MyLib, config: Lib
+      # IncludeDir "MyLib/include" - not needed because this IncludeDir is inherited
+    }
+
+Inject IncludeDir
+=================
+
+.. code-block:: console
+
+    IncludeDir "mock/include", inject: front
+
+"front" is used for mocking IncludeDirs, e.g. if a library shall include a mocked class instead of the original one in UnitTest context.
+
+.. code-block:: console
+
+    IncludeDir include, inject: back
+
+"back" is used if the lower levels do not know by themselves what to include. So this has to be configured from the outside, typically in the main project.
+
+Inject Dependency
+=================
+
+.. code-block:: console
+
+    Dependency MyLib, inject: front # or back
+
+This is used if a component cannot have this dependency hard coded, because it shall not know the concrete implementation or the dependency is only used for unittesting.
+
+Example:
+
+.. code-block:: console
+
+    ExecutableConfig UnitTest {
+      ...
+      Dependency config: Lib
+      Dependency googleTest, inject: front
+    }
+
+In this example the config Lib depends on googleTest. If googleTest inherits an IncludeDir, this would be known by Lib.

data/documentation/_build/html/_sources/concepts/link_order.txt

@@ -1,91 +1,91 @@
-The link order
-==============
-
-The link order depends on the order of library definitions and dependencies in the Project.meta files.
-
-In general, if a library X depends on a library Y, the library X must be linked before Y.
-
-Example:
-********
-
-.. code-block:: console
-
-    Project A:
-
-    Dependency B
-    Dependency C
-
-.. code-block:: console
-
-    Project B:
-
-    Dependency D
-
-.. code-block:: console
-
-    Project C:
-
-    Dependency D
-
-.. code-block:: console
-
-    Project D:
-
-The link order will be
-
-- Objects of A
-- B
-- C
-- D
-
-Same example but with external libraries:
-*****************************************
-
-.. code-block:: console
-
-    Project A:
-
-    ExternalLibrary a1
-    Dependency B
-    ExternalLibrary a2
-    Dependency C
-    ExternalLibrary a3
-
-.. code-block:: console
-
-    Project B:
-
-    ExternalLibrary b1
-    Dependency D
-    ExternalLibrary b2
-
-.. code-block:: console
-
-    Project C:
-
-    ExternalLibrary c1
-    Dependency D
-    ExternalLibrary c2
-
-.. code-block:: console
-
-    Project D:
-
-    ExternalLibrary d1
-    ExternalLibrary d2
-
-The link order will be
-
-- Objects of A
-- a1
-- B
-- b1
-- b2
-- a2
-- C
-- c1
-- D
-- d1
-- d2
-- c2
-- a3
+The link order
+==============
+
+The link order depends on the order of library definitions and dependencies in the Project.meta files.
+
+In general, if a library X depends on a library Y, the library X must be linked before Y.
+
+Example:
+********
+
+.. code-block:: console
+
+    Project A:
+
+    Dependency B
+    Dependency C
+
+.. code-block:: console
+
+    Project B:
+
+    Dependency D
+
+.. code-block:: console
+
+    Project C:
+
+    Dependency D
+
+.. code-block:: console
+
+    Project D:
+
+The link order will be
+
+- Objects of A
+- B
+- C
+- D
+
+Same example but with external libraries:
+*****************************************
+
+.. code-block:: console
+
+    Project A:
+
+    ExternalLibrary a1
+    Dependency B
+    ExternalLibrary a2
+    Dependency C
+    ExternalLibrary a3
+
+.. code-block:: console
+
+    Project B:
+
+    ExternalLibrary b1
+    Dependency D
+    ExternalLibrary b2
+
+.. code-block:: console
+
+    Project C:
+
+    ExternalLibrary c1
+    Dependency D
+    ExternalLibrary c2
+
+.. code-block:: console
+
+    Project D:
+
+    ExternalLibrary d1
+    ExternalLibrary d2
+
+The link order will be
+
+- Objects of A
+- a1
+- B
+- b1
+- b2
+- a2
+- C
+- c1
+- D
+- d1
+- d2
+- c2
+- a3