bake-toolkit 2.20.4 → 2.21.0

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

@@ -1,56 +1,56 @@
-Prebuild configurations for distributions
-*****************************************
-
-This is a useful feature if you want to make a part of workspace available for third party without changing the configuration.
-
-There are two major use cases:
-
-- Only a few projects shall be closed source (e.g. to hide some algorithms)
-- Only a few projects shall be open source (e.g. if a supplier has integrate a library)
-
-Both is possible with bake, but the current UI is optimized for the latter one.
-
-Add in the Project.meta the following code:
-
-.. code-block:: console
-
-    Prebuild {
-      Except main, config: Debug
-      Except newLib, config: Debug
-      Except setup, config: Release
-    }
-
-It is possible to specify the Prebuild tags in all configurations, not only in the main configuration. Logically they will be merged.
-
-In the example above, no configurations will be built - except those three. The prebuild output is used directly.
-
-To reference a configuration of the same project, omit the project name, e.g.:
-
-.. code-block:: console
-
-    Except config: Base
-
-To reference all configuration of a project, omit the config name, e.g.:
-
-.. code-block:: console
-
-    Except newLib
-
-
-This prebuild behaviour must be explicitly turned on by using the following the command line argument:
-
-.. code-block:: console
-
-    --prebuild
-
-
-Typical workflow
-----------------
-
-1. Compiling the workspace completely without prebuild feature.
-2. Executing a distribution script which copies all relevant files to a distribution directory.
-   Make sure to add all header files of prebuild libraries if they are needed for other non-prebuild libraries.
-   You may use the dependency files in the output directory for that script.
-3. In the distribution folder use "--prebuild" when compiling the workspace.
-
-
+Prebuild configurations for distributions
+*****************************************
+
+This is a useful feature if you want to make a part of workspace available for third party without changing the configuration.
+
+There are two major use cases:
+
+- Only a few projects shall be closed source (e.g. to hide some algorithms)
+- Only a few projects shall be open source (e.g. if a supplier has integrate a library)
+
+Both is possible with bake, but the current UI is optimized for the latter one.
+
+Add in the Project.meta the following code:
+
+.. code-block:: console
+
+    Prebuild {
+      Except main, config: Debug
+      Except newLib, config: Debug
+      Except setup, config: Release
+    }
+
+It is possible to specify the Prebuild tags in all configurations, not only in the main configuration. Logically they will be merged.
+
+In the example above, no configurations will be built - except those three. The prebuild output is used directly.
+
+To reference a configuration of the same project, omit the project name, e.g.:
+
+.. code-block:: console
+
+    Except config: Base
+
+To reference all configuration of a project, omit the config name, e.g.:
+
+.. code-block:: console
+
+    Except newLib
+
+
+This prebuild behaviour must be explicitly turned on by using the following the command line argument:
+
+.. code-block:: console
+
+    --prebuild
+
+
+Typical workflow
+----------------
+
+1. Compiling the workspace completely without prebuild feature.
+2. Executing a distribution script which copies all relevant files to a distribution directory.
+   Make sure to add all header files of prebuild libraries if they are needed for other non-prebuild libraries.
+   You may use the dependency files in the output directory for that script.
+3. In the distribution folder use "--prebuild" when compiling the workspace.
+
+

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

@@ -1,45 +1,45 @@
-The main project
-================
-The concept of the main project is different to many other build systems like Eclipse CDT.
-In these build systems everything which is needed for a project is configured in the project itself.
-In bake the main project can predefine stuff for all subprojects.
-The main project can have a DefaultToolchain definition, which is valid for all projects and files referenced by the main project. Subprojects can overwrite or adjust these definitions.
-
-Projects are always built in context of the main project.
-
-To build a project, you have to specify
-
-    * the main project
-    * the config of the main project which references the project to build
-    * the (sub)project to build if applicable
-
-Advantages
-**********
-
-Reducing the number of build configurations (toolchain settings like debug or release flags can be set outside of the project)
-Most projects do not have any compiler definitions anymore
-Only flags which must be used or flags which must not be used have to be specified in the projects
-Changing compiler definitions for all projects can be done easily in the main project build configuration
-
-Example
-*******
-
-==============================================   ==============================================
-Project.meta of Main (Debug and Release)         Project.meta of Sub (only one build config!)
-==============================================   ==============================================
-.. literalinclude:: ../_static/Main.meta         .. literalinclude:: ../_static/Lib.meta
-==============================================   ==============================================
-
-.. note::
-
-    A main project must have a DefaultToolchain - but it's allowed to leave that definition empty.
-
-Output directory
-****************
-
-A project in a specific build configuration can be build in different contexts. 
-That's why the output directory of a project cannot be simply the build configuration name of the project to avoid inconsistencies. 
-Therefore the output directory names are.
-
-    * Main project: $(MainConfigName) like in regular Eclipse CDT builds
-    * Subprojects: $(MainConfigName)_$(MainProjectName) instead of the config name of the subproject
+The main project
+================
+The concept of the main project is different to many other build systems like Eclipse CDT.
+In these build systems everything which is needed for a project is configured in the project itself.
+In bake the main project can predefine stuff for all subprojects.
+The main project can have a DefaultToolchain definition, which is valid for all projects and files referenced by the main project. Subprojects can overwrite or adjust these definitions.
+
+Projects are always built in context of the main project.
+
+To build a project, you have to specify
+
+    * the main project
+    * the config of the main project which references the project to build
+    * the (sub)project to build if applicable
+
+Advantages
+**********
+
+Reducing the number of build configurations (toolchain settings like debug or release flags can be set outside of the project)
+Most projects do not have any compiler definitions anymore
+Only flags which must be used or flags which must not be used have to be specified in the projects
+Changing compiler definitions for all projects can be done easily in the main project build configuration
+
+Example
+*******
+
+==============================================   ==============================================
+Project.meta of Main (Debug and Release)         Project.meta of Sub (only one build config!)
+==============================================   ==============================================
+.. literalinclude:: ../_static/Main.meta         .. literalinclude:: ../_static/Lib.meta
+==============================================   ==============================================
+
+.. note::
+
+    A main project must have a DefaultToolchain - but it's allowed to leave that definition empty.
+
+Output directory
+****************
+
+A project in a specific build configuration can be build in different contexts.
+That's why the output directory of a project cannot be simply the build configuration name of the project to avoid inconsistencies.
+Therefore the output directory names are.
+
+    * Main project: $(MainConfigName) like in regular Eclipse CDT builds
+    * Subprojects: $(MainConfigName)_$(MainProjectName) instead of the config name of the subproject

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

@@ -1,72 +1,72 @@
-The Project.meta file
-=====================
-
-What is the Project.meta file
-*****************************
-The `Project.meta` file is bakes configuration file.
-
-* Every project has a Project.meta file in the project root directory.
-* A Project.meta file contains one or more build configurations.
-* A build configuration consists of toolchain settings, files to build, custom steps, etc.
-
-Example
-*******
-
-=============================================         =============================================
-Project.meta file of Main project                     Project.meta file of Sub project
-=============================================         =============================================
-.. literalinclude:: ../_static/PMetaMain.meta         .. literalinclude:: ../_static/PMetaSub.meta
-=============================================         =============================================
-
-Let's assume that Main and Sub are located in the same workspace root. 
-To build the executable, bake can be called from the Main directory.
-
-    .. code-block:: console
-
-        User@Host:~/my_project$ bake -b Debug
-
-What happens now?
-
-    #. Reading Project.meta of Main
-    #. Reading Project.meta of dependencies (Sub)
-    #. Compiling sources of Sub, e.g.:
-        .. code-block:: console
-
-            User@Host:~$ g++ -c -Wall -g3 -Iinclude -I../Main/include -o Debug_Main/src/xy.o src/xy.cpp
-
-        * Wall is taken from the DefaultToolchain and -g3 is added by the toolchain of the Sub project.
-
-        * The include path to Main is automatically adjusted.
-
-        * The order of includes is the same as in Project.meta.
-
-        * g++, -c and -I are used, because GCC was specified in the DefaultToolchain.
-
-    #. Archiving the library, e.g.:
-
-        .. code-block:: console
-
-            User@Host:~$ ar -rc Debug_Main/libSub.a Debug_Main/src/xy.o
-
-    #. Compiling sources of Main, e.g.:
-
-        .. code-block:: console
-
-            User@Host:~$ g++ -c -Wall -Iinclude -o Debug/src/main.o src/main.cpp
-
-    #. Linking executable, e.g.:
-
-        .. code-block:: console
-
-            User@Host:~$ g++ -o Debug/Main.exe Debug/src/main.o ../Sub/Debug_Main/libSub.a -L../Sub/lib -la -lb
-
-        The library search paths and libraries are added in the specified order.
-
-    #. Executing the post step
-
-        .. code-block:: console
-
-            User@Host:~$ echo Main.exe built.
-
-        The variable was automatically substituted.
-
+The Project.meta file
+=====================
+
+What is the Project.meta file
+*****************************
+The `Project.meta` file is bakes configuration file.
+
+* Every project has a Project.meta file in the project root directory.
+* A Project.meta file contains one or more build configurations.
+* A build configuration consists of toolchain settings, files to build, custom steps, etc.
+
+Example
+*******
+
+=============================================         =============================================
+Project.meta file of Main project                     Project.meta file of Sub project
+=============================================         =============================================
+.. literalinclude:: ../_static/PMetaMain.meta         .. literalinclude:: ../_static/PMetaSub.meta
+=============================================         =============================================
+
+Let's assume that Main and Sub are located in the same workspace root.
+To build the executable, bake can be called from the Main directory.
+
+    .. code-block:: console
+
+        User@Host:~/my_project$ bake -b Debug
+
+What happens now?
+
+    #. Reading Project.meta of Main
+    #. Reading Project.meta of dependencies (Sub)
+    #. Compiling sources of Sub, e.g.:
+        .. code-block:: console
+
+            User@Host:~$ g++ -c -Wall -g3 -Iinclude -I../Main/include -o Debug_Main/src/xy.o src/xy.cpp
+
+        * Wall is taken from the DefaultToolchain and -g3 is added by the toolchain of the Sub project.
+
+        * The include path to Main is automatically adjusted.
+
+        * The order of includes is the same as in Project.meta.
+
+        * g++, -c and -I are used, because GCC was specified in the DefaultToolchain.
+
+    #. Archiving the library, e.g.:
+
+        .. code-block:: console
+
+            User@Host:~$ ar -rc Debug_Main/libSub.a Debug_Main/src/xy.o
+
+    #. Compiling sources of Main, e.g.:
+
+        .. code-block:: console
+
+            User@Host:~$ g++ -c -Wall -Iinclude -o Debug/src/main.o src/main.cpp
+
+    #. Linking executable, e.g.:
+
+        .. code-block:: console
+
+            User@Host:~$ g++ -o Debug/Main.exe Debug/src/main.o ../Sub/Debug_Main/libSub.a -L../Sub/lib -la -lb
+
+        The library search paths and libraries are added in the specified order.
+
+    #. Executing the post step
+
+        .. code-block:: console
+
+            User@Host:~$ echo Main.exe built.
+
+        The variable was automatically substituted.
+

data/documentation/_build/html/_sources/ide/eclipse/eclipse.txt

@@ -1,25 +1,25 @@
-Eclipse
-=======
-
-.. toctree::
-    :maxdepth: 1
-
-    how_to_install_eclipse_plugin
-    how_to_use_bake_in_eclipse
-    how_to_convert_existing_cdt_workspace
-    how_to_create_a_workspace_in_eclipse
-    how_to_create_a_new_project_in_eclipse
-    how_to_debug_in_eclipse
-
-Syntax highlighting
-*******************
-
-To enable syntax highlighting for the Project.meta files in Eclipse, install the "rtext_eclipse_plugin" (Help->Install New Software...) and associate ".meta" files with the rtext editor (Window->Preferences, File Associations page).
-An update site for Eclipse (needed for installation) will be provided soon. For now, you can download it manually at github.
-
-Key bindings
-************
-
-It is possible to bind the bake commands to keys:
-
-.. image:: ../../_static/keys.png
+Eclipse
+=======
+
+.. toctree::
+    :maxdepth: 1
+
+    how_to_install_eclipse_plugin
+    how_to_use_bake_in_eclipse
+    how_to_convert_existing_cdt_workspace
+    how_to_create_a_workspace_in_eclipse
+    how_to_create_a_new_project_in_eclipse
+    how_to_debug_in_eclipse
+
+Syntax highlighting
+*******************
+
+To enable syntax highlighting for the Project.meta files in Eclipse, install the "rtext_eclipse_plugin" (Help->Install New Software...) and associate ".meta" files with the rtext editor (Window->Preferences, File Associations page).
+An update site for Eclipse (needed for installation) will be provided soon. For now, you can download it manually at github.
+
+Key bindings
+************
+
+It is possible to bind the bake commands to keys:
+
+.. image:: ../../_static/keys.png

data/documentation/_build/html/_sources/ide/eclipse/how_to_convert_existing_cdt_workspace.txt

@@ -1,31 +1,31 @@
-How to convert existing CDT workspaces
-======================================
-You only need to convert your workspace if CDT is still used to build your projects and the `Project.meta` files do not exist yet.
-Only one developer in a team has to convert the workspace only once!
-Conversion means, that Project.meta files are generated and filled with the informationen from the `.project` and `.cproject` 
-files. bake does not read the `.project` and `.cproject` files, only the `Project.meta` files.
-
-The converter is an export wizard, which can be found under `File->Export` or in the context menu of the Project Explorer
-
-=========================================           =======================================
-.. image:: ../../_static/SelectExport.png           .. image:: ../../_static/Script.png
-=========================================           =======================================
-
-.. note::
-
-    * The conversion is not a 1:1 conversion. That means, that the tool can only be 99% perfect. There might by some small issues, which have to be adapted manually. You can find it out by simply trying to build your project with bake.
-
-    * It is possible to specify a ruby script in the wizard window, which can do these manual adaptions. This can make sense, if you want to convert the workspace several times before completely switching to bake.
-
-    * To convert only a subset of projects instead of the whole workspace, select the appropriate projects in the Project Explorer before starting the export wizard. Ensure that the checkbox shown above is marked.
-
-    * If you are satisfied with the results, replace the .cproject and .project files in your repository. (Steps to do with .cproject and .project files)
-        * Delete the files
-        * Remove the projects from your workspace in Eclipse (but do not delete the contents from your disk)
-        * Import the projects again via the bake import wizard to generate wrapper files for Eclipse
-        * Commit the change to your source control system
-                   
-.. warning:: 
-    Do not commit these `.projec`t and `.cproject` files anymore. Instead, commit the changes in `Project.meta` files.
-    You still need `.cproject` and `.project` files for working under Eclipse, 
-    that's why you have to import the projects again via the bake import wizard.
+How to convert existing CDT workspaces
+======================================
+You only need to convert your workspace if CDT is still used to build your projects and the `Project.meta` files do not exist yet.
+Only one developer in a team has to convert the workspace only once!
+Conversion means, that Project.meta files are generated and filled with the informationen from the `.project` and `.cproject`
+files. bake does not read the `.project` and `.cproject` files, only the `Project.meta` files.
+
+The converter is an export wizard, which can be found under `File->Export` or in the context menu of the Project Explorer
+
+=========================================           =======================================
+.. image:: ../../_static/SelectExport.png           .. image:: ../../_static/Script.png
+=========================================           =======================================
+
+.. note::
+
+    * The conversion is not a 1:1 conversion. That means, that the tool can only be 99% perfect. There might by some small issues, which have to be adapted manually. You can find it out by simply trying to build your project with bake.
+
+    * It is possible to specify a ruby script in the wizard window, which can do these manual adaptions. This can make sense, if you want to convert the workspace several times before completely switching to bake.
+
+    * To convert only a subset of projects instead of the whole workspace, select the appropriate projects in the Project Explorer before starting the export wizard. Ensure that the checkbox shown above is marked.
+
+    * If you are satisfied with the results, replace the .cproject and .project files in your repository. (Steps to do with .cproject and .project files)
+        * Delete the files
+        * Remove the projects from your workspace in Eclipse (but do not delete the contents from your disk)
+        * Import the projects again via the bake import wizard to generate wrapper files for Eclipse
+        * Commit the change to your source control system
+
+.. warning::
+    Do not commit these `.projec`t and `.cproject` files anymore. Instead, commit the changes in `Project.meta` files.
+    You still need `.cproject` and `.project` files for working under Eclipse,
+    that's why you have to import the projects again via the bake import wizard.