Renamed bfasster.py to run.py

.github/workflows/unittests.yml

@@ -55,7 +55,7 @@ jobs:
       timeout-minutes: 40
       run: |
         source .venv/bin/activate
-        python scripts/bfasster.py --yaml ${{ matrix.experiment }}
+        python scripts/run.py --yaml ${{ matrix.experiment }}
     - name: 'Create fname'
       if: failure()
       id: set-fname

.github/workflows/weeklytests.yml

@@ -46,7 +46,7 @@ jobs:
       timeout-minutes: 40
       run: |
         source .venv/bin/activate
-        python scripts/bfasster.py --yaml ${{ matrix.experiment }}
+        python scripts/run.py --yaml ${{ matrix.experiment }}
     - name: 'Create fname'
       if: failure()
       id: set-fname

README.md

@@ -102,7 +102,7 @@ This branch serves as the transition point to a new version of bfasst, which mak
 There are two steps to running any flow with any design(s): a ninja generation step and a run step. For convenience, a script is included to execute both steps sequentially with a single command:
 
 <pre>Usage:<code>
-    python scripts/bfasster.py [--yaml YAML] [--design DESIGN] [--flow FLOW]
+    python scripts/run.py [--yaml YAML] [--design DESIGN] [--flow FLOW]
 
 options:
     --yaml YAML         The yaml experiment to run, same as with bfasst

project_structure.md

@@ -32,7 +32,7 @@ Also, notice that the journal and log paths are defined in the build snippet on
 
 Ninja templates reside in the ninja_tools subdirectory for the tool that is associated with them. For example, the vivado ninja rule templates are in `ninja_tools/vivado`. RULE SNIPPETS SHOULD BE PLACED IN A SEPARATE FILE FROM BUILD SNIPPETS to maintain the single responsibility principle for tool methods. For example, the build snippet template for vivado synthesis is in `ninja_tools/synth/viv_synth.ninja.mustache` and the snippet that invokes the same rule for implementation is in `ninja_tools/impl/viv_impl.ninja_build.mustache`. Neither of these files contain ninja rules.
 
-The `Flow` objects in bfasst are all responsible for invoking any `Tool` objects that are required for the flow to run and telling them to create their rule and build snippets. The `Tool` objects are responsible for filling in any mustache syntax for its associated rule and build snippets and appending them to the master `build.ninja` file. The `Flow` objects are instantiated automatically by the `FlowManager` object when the `bfasster.py` script is run. There is one flow object for each design that will be included in a given run. All Flow and Tool objects are garbage collected after they have added their rule and build snippets to the `build.ninja` file, and then the `bfasster.py` script runs ninja on the `build.ninja` file.
+The `Flow` objects in bfasst are all responsible for invoking any `Tool` objects that are required for the flow to run and telling them to create their rule and build snippets. The `Tool` objects are responsible for filling in any mustache syntax for its associated rule and build snippets and appending them to the master `build.ninja` file. The `Flow` objects are instantiated automatically by the `FlowManager` object when the `run.py` script is run. There is one flow object for each design that will be included in a given run. All Flow and Tool objects are garbage collected after they have added their rule and build snippets to the `build.ninja` file, and then the `run.py` script runs ninja on the `build.ninja` file.
 
 ## Chevron
 
@@ -98,7 +98,7 @@ The following steps should be taken to add a new flow to the project:
 
 ## add_ninja_deps Method
 
-Each `Flow` and `Tool` object is required to implement the `add_ninja_deps` method. This method should return all src files associated with the object that, if changed, should cause `build.ninja` to *rebuild itself*. We provide a `configure` rule that will rebuild `build.ninja` when these files change. If none of these dependencies change, and the flow and designs stay the same, then `build.ninja` will not be rebuild the next time `bfasster.py` is run. The `add_ninja_deps` method should in every case extend the provided `deps` list with paths to all dependency files associated with the object. For example, the `Flow` object for the `vivado` flow is as follows:
+Each `Flow` and `Tool` object is required to implement the `add_ninja_deps` method. This method should return all src files associated with the object that, if changed, should cause `build.ninja` to *rebuild itself*. We provide a `configure` rule that will rebuild `build.ninja` when these files change. If none of these dependencies change, and the flow and designs stay the same, then `build.ninja` will not be rebuild the next time `run.py` is run. The `add_ninja_deps` method should in every case extend the provided `deps` list with paths to all dependency files associated with the object. For example, the `Flow` object for the `vivado` flow is as follows:
 
 ```py
 def add_ninja_deps(self, deps):

test/scripts/test_bfasster.py → test/scripts/test_run.py

@@ -6,15 +6,15 @@
 from contextlib import redirect_stderr
 from bfasst.paths import ROOT_PATH
 
-from scripts.bfasster import parse_args
+from scripts.run import parse_args
 
 
 class TestBfassterApplicationRunner(unittest.TestCase):
     """Unit tests for the bfasster ApplicationRunner class."""
 
     def __run_flow(self, flow):
         # run the bfasster script with the given flow
-        cmd = ["python", "scripts/bfasster.py", "--design", "byu/alu", "--flow", flow]
+        cmd = ["python", "scripts/run.py", "--design", "byu/alu", "--flow", flow]
 
         # capture the output of the runner with subprocess.PIPE so it doesn't print to the console.
         # the first time bfasster runs, ninja will get everything up to date.