regex change of level 1 headers to ====\nTEXT\n==== and level 2 heade…

…rs to TEXT\n====

build/buildScript.rst

@@ -1,7 +1,6 @@
 .. _build/buildScript:
 
-build system build script (build.sh or build.bat)
-=================================================
+=================================================build system build script (build.sh or build.bat)=================================================
 
 :Status: Draft
 :Version: 1.0
@@ -11,7 +10,6 @@ build system build script (build.sh or build.bat)
 .. contents::
    :depth: 2
 
-============
 Introduction
 ============
 
@@ -23,7 +21,6 @@ The ``build.sh`` (unix) or ``build.bat`` (Windows) script located in the Dojo so
 
   * Any of the following parameters can be set directly in the profile file as part of the overall `dependencies` Object
 
-=====
 Usage
 =====
 
@@ -145,7 +142,6 @@ xdDojoScopeName=dojo
 buildLayers=
   A comma-separated list of layer names to build. Using this option means that only those layers will be built. This helps if you are doing quick development and test cycles with layers. If you have problems using this option, try removing it and doing a full build with action=clean,release. This build option assumes you have done at least one full build first.
 
-========
 Examples
 ========
 

build/buildSystem.rst

@@ -1,7 +1,6 @@
 .. _build/buildSystem:
 
-The Dojo Build System
-=====================
+=====================The Dojo Build System=====================
 
 :Status: Draft
 :Version: 1.7+
@@ -15,9 +14,8 @@ version 1.7 is available* :ref:`here <build/pre17/build>`.
 
 *See* :ref:`The Dojo Build System <build/index>` *for a complete list of build system documentation resources.*
 
-============
-Introduction
-============
+Command Line Switches
+=====================
 
 The Dojo build system is a general-purpose program for transforming a set of resources. It was built to solve the
 problem of transforming a set of resources that comprise an application in order to improve the performance of that
@@ -48,9 +46,8 @@ processes can be executed as well.
 This document describes using the build system for deployment optimizations. See xxx for information about writing your
 own custom transforms and configuring the build system for other uses.
 
-========
-Overview
-========
+Command Line Switches
+=====================
 
 The design of the system is simple. It "discovers" a set of resources and then applies a synchronized, ordered set of
 resource-dependent transforms to those resources. Both the discovery process and the transforms are controlled by a
@@ -105,9 +102,8 @@ These are discussed in separate documents as follows:
 
 * For a description of backward compatibility features see :ref:`Processing Legacy Build Profiles <build/legacyBackCompat>`.
 
-========================
-Assumptions for Examples
-========================
+Command Line Switches
+=====================
 
 This document contains several examples. It assumes the source distribution of the Dojo Toolkit, version 1.7 or greater,
 is installed at ~/dev/dtk/. If you are a Windows user, "~" is shorthand for the user's home directory; substitute
@@ -118,9 +114,8 @@ Unless specifically stated otherwise, all examples assume the current working di
 ~/dev/dtk/util/buildscripts. As we'll see, this is not a requirement of the the build system, both rather a convenience
 so you don't have to path to the build system executable.
 
-=========================
-Invoking the Build System
-=========================
+Command Line Switches
+=====================
 
 The build system is a Javascript program comprised of a set of AMD modules that may be executed by node.js or Rhino. The
 program is distributed with the source version of the Dojo Toolkit. The source tree resides at util/build/. Dojo can be
@@ -173,7 +168,6 @@ Although the legacy build system could be executed when /util/buildscripts/ was
 do so required a carefully constructed profile. Indeed, many profiles provided with Dojo source distributions won't work
 unless /util/buildscripts/ is the current working directory. The current build system has no such restriction.
 
-=====================
 Command Line Switches
 =====================
 
@@ -234,7 +228,6 @@ understanding and debugging how a particular build system invocation is consumin
 This example points out that number, true, false, and null values are not stored as strings but rather are converted to
 Javascript numbers, booleans, and null.
 
-==============
 Profile Basics
 ==============
 
@@ -447,7 +440,6 @@ represents. Also notice that the property :ref:``selfFilename`` is set the the a
 resides and is added to the package.Json object. This gives the reference path for any relative paths found in the
 package.json object, the ``directories.lib`` path in particular.
 
-====================
 Specifying Resources
 ====================
 
@@ -889,7 +881,6 @@ Don't be concerned about the need to download an extra resource to configure the
 the writeDojo transform allows a customized configuration to be embedded in the loader resource and the replacements
 transform allows chunks of resources, like the configuration script element, to be replaced--perhaps with nothing.
 
-=============
 Resource Tags
 =============
 
@@ -917,7 +908,6 @@ tags:
 ``miniExclude``
   The resource should not be copied to the destination if the profile property "mini" is truthy.
 
-==========
 Transforms
 ==========
 
@@ -956,7 +946,6 @@ for complete documentation.
 
 * :ref:`writeOptimized <build/transforms/writeOptimized>`: Processes a resource with shrinksafe or the closure compiler and writes the result to the file system.
 
-===================
 Applying Transforms
 ===================
 
@@ -1047,7 +1036,6 @@ below, in the order listed. The first test that passes indicates the transforms
 
   * Copy resource from source location to destination location (copy).
 
-===========================================
 Command Line and Profile Property Reference
 ===========================================
 

build/customBase.rst

@@ -1,7 +1,6 @@
 .. _build/customBase:
 
-build customBase
-================
+================build customBase================
 
 :Author: Scott Jenkins
 :Project owner: ?
@@ -13,7 +12,6 @@ build customBase
 Custom base is used to make an extremely small file size version of dojo.js.
 
 
-============
 Introduction
 ============
 
@@ -24,7 +22,6 @@ However, in some cases, such as creating web applications intended for use on sm
 This is a very advanced feature, and if you think you need to use it, you should think carefully first. If after careful consideration, you still want to use this feature, be very, very careful and document it thoroughly for your own understanding.
 
 
-===============================
 dojo.require for base functions
 ===============================
 
@@ -35,7 +32,6 @@ Instead, a ``dojo.require`` statement is generated for each base resource that t
 This allows you to still use the entire base API, but at the cost of additional an additional round trip to the server *at the time a function not in base is first called*.
 
 
-=====
 Usage
 =====
 
@@ -70,7 +66,6 @@ You just end up with the following from ``dojo/_base/_loader``, basically, just
    * ``loader.js``
 
 
-============================
 Including Specific Resources
 ============================
 
@@ -92,7 +87,6 @@ look like this:
    }
 
 
-===================
 Caveats
 ===================
 
@@ -113,7 +107,6 @@ finds "indexOf" in the module, it will add in a
 have been a String method call.
 
 
-================
 Known Bugs
 ================
 

build/directoryLayout.rst

@@ -1,5 +1,6 @@
 .. _build/directoryLayout:
 
+==================================
 Sample Directory Layout for Builds
 ==================================
 
@@ -14,7 +15,6 @@ Sample Directory Layout for Builds
 This document summarizes an effective layout for managing Dojo directories for the build process.
 
 
-============
 Introduction
 ============
 
@@ -28,7 +28,6 @@ This directory layout (which is used in each of the scenario examples) facilitat
  2.  No additional build files are mixed into any private namespace directory trees.
  3.  The build files (profiles and other support files) do not need to be moved into new specific directories each time a new version of Dojo is released, or a new version of a custom namespace is created.
 
-================
 Directory Layout
 ================
 

build/exclude.rst

@@ -1,5 +1,6 @@
 .. _build/exclude:
 
+==========================================
 Dojo build system:  conditional exclusions
 ==========================================
 
@@ -12,7 +13,6 @@ Dojo build system:  conditional exclusions
    :depth: 3
 
 
-============
 Introduction
 ============
 
@@ -24,7 +24,6 @@ This is somewhat analogous to the use of ``#ifdef`` pragmas within the C pre-pro
 
 For example, you might wish to strip a profiling module from a release build but include it in a development build.
 
-======
 Syntax
 ======
 
@@ -55,7 +54,6 @@ where
 
 Note:  the tag for the excludeStart pragma must be equal to the tag for the excludeEnd pragma.
 
-=========
 Condition
 =========
 
@@ -65,13 +63,11 @@ This parameter is actually JavaScript code which is evaluated by the builder at
 
 The object you most commonly will evaluate against is ``kwArgs`` which is where the builder stores its profile (it actually stores all of its parameters there, whether they originate in the profile, on the build command line, or from the builders' built in defaults).
 
-===============
 Builder Objects
 ===============
 
 TODOC:  Document builder objects of interest
 
-============================
 Nesting conditional excludes
 ============================
 
@@ -94,7 +90,6 @@ If you do nest, the exclusion regions must be fully and properly nested.  Thus,
 
 because the named regions overlap.
 
-========
 See also
 ========
 

build/expand-provide.rst

@@ -1,5 +1,6 @@
 .. _build/expand-provide:
 
+============================
 Expanding dojo.provide calls
 ============================
 
@@ -12,13 +13,11 @@ Expanding dojo.provide calls
 
 Expands dojo.provide calls with faster calls at the expense of a larger file size in built layers.
 
-============
 Introduction
 ============
 
 The Dojo Build provides a mechanism for expanding :ref:`dojo.provide <dojo/provide>` calls within your code into faster javascript equivalents, avoiding expensive lookups through :ref:`dojo.getObject <dojo/getObject>` when it is otherwise safe to assume. This is a simple toggle on a build command line or profile called "expandProvide", and defaults to 'false'.
 
-=====
 Usage
 =====
 

build/index.rst

@@ -1,13 +1,13 @@
 .. _build/index:
 
+=====================
 The Dojo Build System
 =====================
 
 :Status: Draft
 :Version: 1.7+
 :Author: Rawld Gill
 
-=====================
 The Dojo Build System
 =====================
 
@@ -33,7 +33,6 @@ All historical documentation for that system is listed at
 :ref:`Quick Reference for Optimization Build Program <build/qref>`
   A quick reference manual for all build system switches and knobs.
 
-==================================
 Deployment Optimization Transforms
 ==================================
 
@@ -88,7 +87,6 @@ for complete documentation.
 :ref:`writeOptimized <build/transforms/writeOptimized>`
   Processes a resource with shrinksafe or the closure compiler and writes the result to the file system.
 
-==========================================
 The Dojo Build System Prior to version 1.7
 ==========================================
 

build/keepRequires.rst

@@ -1,5 +1,6 @@
 .. _build/keepRequires:
 
+==================================
 Dojo build system:  keepRequires
 ==================================
 
@@ -11,7 +12,6 @@ Dojo build system:  keepRequires
 .. contents::
    :depth: 3
 
-============
 Introduction
 ============
 
@@ -37,15 +37,13 @@ However, the penalty for doing so is that the module would be downloaded at runt
 
 Note:  The builder uses a regular expression to locate ``dojo.require`` statements within the code it is building.  If you specify dojo require using the notation ``dojo["require"]("module name")``, the builder will not try to include that resource, which has the same affect as excluding it your build file via the layer's ``keepRequires`` property.  This technique is obscure and inelegant and may not be obvious later, so use it with caution.
 
-======
 Syntax
 ======
 
 ``keepRequires`` is a property that you can add to each ``layers`` member within your profile.  It must be an array of strings, which represent the modules that should not be included in the layer.
 
 TODOC:  Make an example profile, but people who would use this feature shouldn't need !
 
-========
 See also
 ========