Fix links

Signed-off-by: Jeff Goeders <[email protected]>

Author: jgoeders

BUILDING.md

@@ -31,7 +31,7 @@ From the top-level, run:
 The complete VTR flow has been tested on 64-bit Linux systems.
 The flow should work in other platforms (32-bit Linux, Windows with cygwin) but this is untested.
 
-*See Also:* Full information about building VTR, including setting up required system packages and Python packages, can be found in [Optional Build Information](doc/src/vtr/optional_build_info.md) page.
+*Full information about building VTR, including setting up required system packages and Python packages, can be found in [Optional Build Information](doc/src/vtr/optional_build_info.md) page.*
 
 Please [let us know](doc/src/contact.md) your experience with building VTR so that we can improve the experience for others.
 

CONTRIBUTING.md

@@ -154,7 +154,7 @@ The following are general tips for making your pull requests easy to review (and
 * Keep changes small
 
     Large change sets are difficult and time-consuming to review.
-    If a change set is becoming too large, consider splitting it into smaller pieces; you'll probably want to [file an issue](#filling-feature-requests) to discuss things first.
+    If a change set is becoming too large, consider splitting it into smaller pieces; you'll probably want to [file an issue](#filling-enhancement-requests) to discuss things first.
 
 * Do one thing only
 

README.developers.md

@@ -966,7 +966,7 @@ $ make
 this turns on more extensive assertion checking and re-builds VTR.
 
 ## GDB Pretty Printers
-To make it easier to debug some of VTR's data structures with [GDB](www.gnu.org/gdb).
+To make it easier to debug some of VTR's data structures with [GDB](https://www.sourceware.org/gdb/).
 
 ### STL Pretty Printers
 
@@ -1145,7 +1145,7 @@ make CMAKE_PARAMS="-DVTR_IPO_BUILD=off" -j8 vpr
 # External Subtrees
 VTR includes some code which is developed in external repositories, and is integrated into the VTR source tree using [git subtrees](https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree).
 
-To simplify the process of working with subtrees we use the [`dev/external_subtrees.py`](./dev/external_subtrees.py) script.
+To simplify the process of working with subtrees we use the [`dev/external_subtrees.py`](https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/dev/external_subtrees.py) script.
 
 For instance, running `./dev/external_subtrees.py --list` from the VTR root it shows the subtrees:
 ```
@@ -1159,15 +1159,15 @@ Component: libtatum        Path: libs/EXTERNAL/libtatum         URL: https://git
 Code included in VTR by subtrees should *not be modified within the VTR source tree*.
 Instead changes should be made in the relevant up-stream repository, and then synced into the VTR tree.
 
-### Updating an existing Subtree
+## Updating an existing Subtree
 1. From the VTR root run: `./dev/external_subtrees.py $SUBTREE_NAME`, where `$SUBTREE_NAME` is the name of an existing subtree.
 
     For example to update the `libtatum` subtree:
     ```shell
     ./dev/external_subtrees.py --update libtatum
     ```
 
-### Adding a new Subtree
+## Adding a new Subtree
 
 To add a new external subtree to VTR do the following:
 
@@ -1207,7 +1207,7 @@ To add a new external subtree to VTR do the following:
     The first will squash all the upstream changes, the second will merge those changes into the current branch.
 
 
-### Subtree Rational
+## Subtree Rational
 
 VTR uses subtrees to allow easy tracking of upstream dependencies.
 
@@ -1221,7 +1221,7 @@ See [here](https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git
 # Finding Bugs with Coverity
 [Coverity Scan](https://scan.coverity.com) is a static code analysis service which can be used to detect bugs.
 
-### Browsing Defects
+## Browsing Defects
 To view defects detected do the following:
 
 1. Get a coverity scan account
@@ -1231,7 +1231,7 @@ To view defects detected do the following:
 2. Browse the existing defects through the coverity web interface
 
 
-### Submitting a build
+## Submitting a build
 To submit a build to coverity do the following:
 
 1. [Download](https://scan.coverity.com/download) the coverity build tool
@@ -1264,7 +1264,7 @@ Note that we explicitly asked for gcc and g++, the coverity build tool defaults
 
 Once the build has been analyzed you can browse the latest results through the coverity web interface
 
-### No files emitted
+## No files emitted
 If you get the following warning from cov-build:
 
     [WARNING] No files were emitted.
@@ -1303,5 +1303,5 @@ The following outlines the procedure to following when making an official VTR re
  * GitHub will automatically create a release based on the tag
  * Add the new change log entry to the [GitHub release description](https://github.com/verilog-to-routing/vtr-verilog-to-routing/releases)
  * Update the [ReadTheDocs configuration](https://readthedocs.org/projects/vtr/versions/) to build and serve documentation for the relevant tag (e.g. `v8.0.0`)
- * Send a release announcement email to the [vtr-announce]([email protected]) mailing list (make sure to thank all contributors!)
+ * Send a release announcement email to the [vtr-announce](mailto:[email protected]) mailing list (make sure to thank all contributors!)
 

doc/src/LICENSE.md

@@ -0,0 +1,2 @@
+```{include} ../../LICENSE.md
+```

doc/src/conf.py

@@ -372,7 +372,7 @@
             assert os.path.exists(prjdir) == True, "Regenerate doxygen XML for {}".format(prjname)
 
 # Add page anchors for myst parser
-myst_heading_anchors = 3
+myst_heading_anchors = 4
 
 
 def setup(app):

doc/src/dev/contributing/contributing.md

@@ -11,5 +11,5 @@ Developer Guide
     c_api_doc
     code_documentation
     tutorials/index
-    support
-    license
+    ../SUPPORT
+    ../LICENSE

doc/src/dev/contributing/index.rst

@@ -12,7 +12,7 @@ To create a pull request, clone the [vtr-verilog-to-routing repository](https://
 Make changes to the branch that improve Odin II and correct the bug.
 **Important** In addition to correcting the bug, it is required that test cases (benchmarks) are created that reproduce the issue and are included in the regression tests.
 An example of a good test case could be the benchmark found in the "Issue" being addressed.
-The results of these new tests need to be regenerate. See [regression tests](./regression_tests) for further instruction.
+The results of these new tests need to be regenerate. See [regression tests](regression_test.md) for further instruction.
 Push these changes to the cloned repository and create the pull request.
 Add a description of the changes made and reference the "issue" that it corrects. There is a template provided on GitHub.
 
@@ -29,7 +29,7 @@ Then, create a pull request with that branch and **include WIP in the title.**
 This will automatically indicate that this PR is not ready to be merged.
 Continue to work on the branch, pushing the commits regularly.
 Like a PR, test cases must be included through the use of benchmarks.
-See [regression tests](./regression_tests) for further instruction.
+See [regression tests](regression_test.md) for further instruction.
 
 ### Formating
 

doc/src/dev/developing.md

@@ -54,11 +54,9 @@ from the VTR root directory (hereafter referred to as :term:`$VTR_ROOT`) to buil
     To run the examples in this guide on your machine, either:
 
     * define VTR_ROOT as a variable in your shell (e.g. if ``~/trees/vtr`` is the path to the VTR source tree on your machine, run the equivalent of ``VTR_ROOT=~/trees/vtr`` in BASH) which will allow you to run the commands as written in this guide, or
-    * manually replace `$VTR_ROOT` in the example commandss below with your path to the VTR source tree.
+    * manually replace `$VTR_ROOT` in the example commands below with your path to the VTR source tree.
 
-.. note:: If VTR fails to build you may need to install the :ref:`required dependencies <building_vtr>`.
-
-For more details on building VTR on various operating systems/platforms see :ref:`Building VTR<building_vtr>`.
+For more details on building VTR on various operating systems/platforms see :doc:`Building VTR</BUILDING>`.
 
 
 Running VPR
@@ -487,7 +485,7 @@ Here are some possible next steps for users wishing to use VTR:
 
  * Discover how to :ref:`generate FASM <genfasm>` for bitstream creation.
 
- * :ref:`Suggest or make enhancements to VTR's documentation <contribution_guidelines>`.
+ * :doc:`Suggest or make enhancements to VTR's documentation </CONTRIBUTING>`.
 
 Here are some possible next steps for developers wishing to modify and improve VTR:
 
@@ -497,6 +495,6 @@ Here are some possible next steps for developers wishing to modify and improve V
 
  * Read through the :ref:`developer guide <developer_guide>`.
 
- * Look for :ref:`open issues to which you can contribute <contribution_guidelines>`.
+ * Look for :doc:`open issues to which you can contribute </CONTRIBUTING>`.
 
  * Begin exploring the source code for the main tools in VTR (e.g. VPR in ``$VTR_ROOT/vpr/src``).

doc/src/dev/index.rst

@@ -78,7 +78,7 @@ Here are some highlights of the |version| full release:
   Along with experiments for more conventional FPGAs, we also include an experiment that explores FPGAs with embedded floating-point cores investigated in :cite:`ho_floating_point_fpga` to illustrate the usage of the VTR framework to explore unconventional FPGA architectures.
 
 Development Repository
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~
 The development repository for the Verilog-to-Routing project is hosted at:
 
     https://github.com/verilog-to-routing/vtr-verilog-to-routing