From: Erik Faye-Lund Date: Sat, 27 Jun 2020 08:00:10 +0000 (+0200) Subject: docs: use ref-links for internal references X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=b1c16e52514fd9e66d3ac118f1ec32a83cbc5f2a;p=mesa.git docs: use ref-links for internal references Ref-link have two benefits over generic links: 1. They produce the right result for non-HTML outputs 2. They get validated at build-time So let's use them for internal references instead. Reviewed-by: Eric Engestrom Part-of: --- diff --git a/docs/dispatch.rst b/docs/dispatch.rst index 470b9809bd1..6b808597310 100644 --- a/docs/dispatch.rst +++ b/docs/dispatch.rst @@ -5,7 +5,7 @@ Several factors combine to make efficient dispatch of OpenGL functions fairly complicated. This document attempts to explain some of the issues and introduce the reader to Mesa's implementation. Readers already familiar with the issues around GL dispatch can safely skip ahead to the -`overview of Mesa's implementation <#overview>`__. +:ref:`overview of Mesa's implementation `. 1. Complexity of GL Dispatch ---------------------------- @@ -162,7 +162,7 @@ dispatch routines are very short, and it is trivial to create optimal assembly language versions. The amount of optimization provided by using assembly stubs varies from platform to platform and application to application. However, by using the assembly stubs, many platforms can -use an additional space optimization (see `below <#fixedsize>`__). +use an additional space optimization (see :ref:`below `). The biggest hurdle to creating assembly stubs is handling the various ways that the dispatch table pointer can be accessed. There are four diff --git a/docs/meson.rst b/docs/meson.rst index 8166192b9ff..89eeb7e7bf5 100644 --- a/docs/meson.rst +++ b/docs/meson.rst @@ -290,7 +290,7 @@ Then configure meson: meson builddir/ --cross-file cross-llvm.ini -See the `Cross Compilation <#cross-compilation>`__ section for more +See the :ref:`Cross Compilation ` section for more information. On windows (and in other cases), using llvm-config or cmake may be diff --git a/docs/repository.rst b/docs/repository.rst index aa812345d55..8172793009a 100644 --- a/docs/repository.rst +++ b/docs/repository.rst @@ -7,8 +7,8 @@ system. The master git repository is hosted on `freedesktop.org `__. -You may access the repository either as an `anonymous -user <#anonymous>`__ (read-only) or as a `developer <#developer>`__ +You may access the repository either as an :ref:`anonymous +user ` (read-only) or as a :ref:`developer ` (read/write). You may also `browse the main Mesa git diff --git a/docs/submittingpatches.rst b/docs/submittingpatches.rst index e51105dc22f..98398d972ab 100644 --- a/docs/submittingpatches.rst +++ b/docs/submittingpatches.rst @@ -14,11 +14,11 @@ Basic guidelines components. - Patches should never introduce build breaks and should be bisectable (see ``git bisect``.) -- Patches should be properly `formatted <#formatting>`__. -- Patches should be sufficiently `tested <#testing>`__ before +- Patches should be properly :ref:`formatted `. +- Patches should be sufficiently :ref:`tested ` before submitting. -- Patches should be `submitted <#submit>`__ via a merge request for - `review <#reviewing>`__. +- Patches should be :ref:`submitted ` via a merge request for + :ref:`review `. .. _formatting: @@ -64,7 +64,7 @@ Patch formatting **Do not use the ``Fixes:`` tag for this!** Mesa already uses ``Fixes:`` for something else. - See `below <#fixes>`__. + See :ref:`below `. - If there have been several revisions to a patch during the review process, they should be noted such as in this example: @@ -126,7 +126,7 @@ The stable tag If you want a commit to be applied to a stable branch, you should add an appropriate note to the commit message. -Using a ``Fixes:`` tag as described in `Patch formatting <#formatting>`__ +Using a ``Fixes:`` tag as described in :ref:`Patch formatting ` is the preferred way to nominate a commit that should be backported. There are scripts that will figure out which releases to apply the patch to automatically, so you don't need to figure it out. @@ -286,8 +286,8 @@ is not monitored actively and is a historical artifact. If you are not the author of the original patch, please Cc: them in your nomination request. -The current patch status can be observed in the `staging -branch `__. +The current patch status can be observed in the :ref:`staging +branch `. .. _criteria: @@ -301,7 +301,7 @@ mechanism described above. The following rules define which patches are accepted and which are not. The stable-release manager is also given broad discretion in rejecting patches that have been nominated. -- Patch must conform with the `Basic guidelines <#guidelines>`__ +- Patch must conform with the :ref:`Basic guidelines ` - Patch must have landed in master first. In case where the original patch is too large and/or otherwise contradicts with the rules set within, a backport is appropriate. @@ -319,7 +319,7 @@ broad discretion in rejecting patches that have been nominated. .. note:: An exception to this rule, are hardware-enabling "features". For - example, `backports <#backports>`__ of new code to support a + example, :ref:`backports ` of new code to support a newly-developed hardware product can be accepted if they can be reasonably determined not to have effects on other hardware.