Add a linkchecker target for checking broken links in SWIGDocumentation.html

9 files changed, 29 insertions, 21 deletions

diff --git a/Doc/Manual/Android.html b/Doc/Manual/Android.html
index 2890e2415..ae610b7d8 100644
--- a/Doc/Manual/Android.html
+++ b/Doc/Manual/Android.html
@@ -36,7 +36,7 @@ This chapter describes SWIG's support of Android.
 <p>
 The Android chapter is fairly short as support for Android is the same as for Java, where the Java Native Interface (JNI) is
 used to call from Android Java into C or C++ compiled code.
-Everything in the <a href="Java.html">Java chapter</a> applies to generating code for access from Android Java code.
+Everything in the <a href="Java.html#Java">Java chapter</a> applies to generating code for access from Android Java code.
 This chapter contains a few Android specific notes and examples.
 </p>
 
diff --git a/Doc/Manual/CSharp.html b/Doc/Manual/CSharp.html
index 18fc3037e..e55013b1c 100644
--- a/Doc/Manual/CSharp.html
+++ b/Doc/Manual/CSharp.html
@@ -1740,7 +1740,7 @@ should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C
 
 
 <p>
-When using <a href="Modules.html">multiple modules</a> it is is possible to compile each SWIG generated wrapper
+When using <a href="Modules.html#Modules">multiple modules</a> it is is possible to compile each SWIG generated wrapper
 into a different assembly.
 However, by default the generated code may not compile if 
 generated classes in one assembly use generated classes in another assembly.
diff --git a/Doc/Manual/D.html b/Doc/Manual/D.html
index 47dab50f1..984b81bb8 100644
--- a/Doc/Manual/D.html
+++ b/Doc/Manual/D.html
@@ -50,7 +50,7 @@
 
 <p>While these issues can be worked around relatively easy by hand-coding a thin wrapper layer around the C library in question, there is another issue where writing wrapper code per hand is not feasible: C++ libraries. D did not support interfacing to C++ in version 1 at all, and even if <tt>extern(C++)</tt> has been added to D2, the support is still very limited, and a custom wrapper layer is still required in many cases. </p>
 
-<p>To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on <a href="CSharp.html">C#</a> (and also on <a href="Java.html">Java</a>, since the C# module was in turn forked from it).</p>
+<p>To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on <a href="CSharp.html#CSharp">C#</a> (and also on <a href="Java.html#Java">Java</a>, since the C# module was in turn forked from it).</p>
 
 
 <H2><a name="D_command_line_invocation"></a>22.2 Command line invocation</H2>
@@ -64,7 +64,7 @@
     <p>By default, SWIG generates code for D1/Tango. Use the <tt>-d2</tt> flag to target D2/Phobos instead.</p>
   </dd>
 
-  <dt id="D_splitproxy"><tt>-splitproxy</tt></dt>
+  <dt><a name="D_splitproxy"></a><tt>-splitproxy</tt></dt>
   <dd>
     <p>By default, SWIG generates two D modules: the <em>proxy</em> module, named like the source module (either specified via the <tt>%module</tt> directive or via the <tt>module</tt> command line switch), which contains all the proxy classes, functions, enums, etc., and the <em>intermediary</em> module (named like the proxy module, but suffixed with <tt>_im</tt>), which contains all the <tt>extern(C)</tt> function declarations and other private parts only used internally by the proxy module.</p>
     <p>If the split proxy mode is enabled by passing this switch at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.</p>
@@ -125,7 +125,7 @@
 
 <p>Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).</p>
 
-<p>The code from the <tt>in</tt> typemap is used to convert arguments to the C wrapper function to the type used in the wrapped code (<tt>ctype</tt>->original C++ type), the <tt>out</tt> typemap is utilized to convert values from the wrapped code to wrapper function return types (original C++ type-><tt>ctype</tt>).</p>
+<p>The code from the <tt>in</tt> typemap is used to convert arguments to the C wrapper function to the type used in the wrapped code (<tt>ctype</tt>-&gt;original C++ type), the <tt>out</tt> typemap is utilized to convert values from the wrapped code to wrapper function return types (original C++ type-&gt;<tt>ctype</tt>).</p>
 
 <p>The <tt>directorin</tt> typemap is used to convert parameters to the type used in the D director callback function, its return value is processed by <tt>directorout</tt> (see below).</p>
 
@@ -135,11 +135,11 @@
 
 <p>Typemaps for code generation in D proxy and type wrapper classes.</p>
 
-<p id="D_din">The <tt>din</tt> typemap is used for converting function parameter types from the type used in the proxy module or class to the type used in the intermediary D module (the <a href="D.html#D_dinput"><tt>$dinput</tt></a> macro is replaced). To inject further parameter processing code before or after the call to the intermediary layer, the <tt>pre</tt>, <tt>post</tt> and <tt>terminator</tt> attributes can be used (please refer to the <a href="CSharp.html#CSharp_date_marshalling">C# date marshalling example</a> for more information on these).</p>
+<p><a name="D_din"></a>The <tt>din</tt> typemap is used for converting function parameter types from the type used in the proxy module or class to the type used in the intermediary D module (the <a href="D.html#D_dinput">$dinput</a> macro is replaced). To inject further parameter processing code before or after the call to the intermediary layer, the <tt>pre</tt>, <tt>post</tt> and <tt>terminator</tt> attributes can be used (please refer to the <a href="CSharp.html#CSharp_date_marshalling">C# date marshalling example</a> for more information on these).</p>
 
-<p id="D_dout">The <tt>dout</tt> typemap is used for converting function return values from the return type used in the intermediary D module to the type returned by the proxy function. The <tt>$excode</tt> special variable in <tt>dout</tt> typemaps is replaced by the <tt>excode</tt> typemap attribute code if the method can throw any exceptions from unmanaged code, otherwise by nothing (the <a href="D.html#D_imcall"><tt>$imcall</tt> and <tt>$owner</tt></a> macros are replaced).</p>
+<p><a name="D_dout"></a>The <tt>dout</tt> typemap is used for converting function return values from the return type used in the intermediary D module to the type returned by the proxy function. The <tt>$excode</tt> special variable in <tt>dout</tt> typemaps is replaced by the <tt>excode</tt> typemap attribute code if the method can throw any exceptions from unmanaged code, otherwise by nothing (the <a href="D.html#D_imcall"><tt>$imcall</tt> and <tt>$owner</tt></a> macros are replaced).</p>
 
-<p id="D_ddirectorinout">The code from the <tt>ddirectorin</tt> and <tt>ddirectorout</tt> typemaps is used for conversion in director callback functions. Arguments are converted to the type used in the proxy class method they are calling by using the code from <tt>ddirectorin</tt>, the proxy class method return value is converted to the type the C++ code expects via the <tt>ddirectorout</tt> typemap (the <a href="D.html#D_dpcall"><tt>$dcall</tt> and <tt>$winput</tt></a> macros are replaced).</p>
+<p><a name="D_ddirectorinout"></a>The code from the <tt>ddirectorin</tt> and <tt>ddirectorout</tt> typemaps is used for conversion in director callback functions. Arguments are converted to the type used in the proxy class method they are calling by using the code from <tt>ddirectorin</tt>, the proxy class method return value is converted to the type the C++ code expects via the <tt>ddirectorout</tt> typemap (the <a href="D.html#D_dpcall"><tt>$dcall</tt> and <tt>$winput</tt></a> macros are replaced).</p>
 
 <p>The full chain of type conversions when a director callback is invoked looks like this:</p>
 
@@ -172,7 +172,7 @@
 
 <p>Using <tt>dcode</tt> and <tt>dimports</tt>, you can specify additional D code which will be emitted into the class body respectively the imports section of the D module the class is written to.</p>
 
-<p id="D_class_code_typemaps"><tt>dconstructor</tt>, <tt>ddestructor</tt>, <tt>ddispose</tt> and <tt>ddispose_derived</tt> are used to generate the class constructor, destructor and <tt>dispose()</tt> method, respectively. The auxiliary code for handling the pointer to the C++ object is stored in <tt>dbody</tt> and <tt>dbody_derived</tt>. You can override them for specific types.</p>
+<p><a name="D_class_code_typemaps"></a><tt>dconstructor</tt>, <tt>ddestructor</tt>, <tt>ddispose</tt> and <tt>ddispose_derived</tt> are used to generate the class constructor, destructor and <tt>dispose()</tt> method, respectively. The auxiliary code for handling the pointer to the C++ object is stored in <tt>dbody</tt> and <tt>dbody_derived</tt>. You can override them for specific types.</p>
 
 
 <H3><a name="D_special_variables"></a>22.3.7 Special variable macros</H3>
@@ -197,7 +197,7 @@
   <dt><tt>$null</tt></dt>
   <dd><p>In code inserted into the generated C/C++ wrapper functions, this variable is replaced by either <tt>0</tt> or nothing at all, depending on whether the function has a return value or not. It can be used to bail out early e.g. in case of errors (<tt>return $null;</tt>).</p></dd>
 
-  <dt id="D_dinput"><tt>$dinput</tt> (C#: <tt>$csinput</tt>)</dt>
+  <dt><a name="D_dinput"></a><tt>$dinput</tt> (C#: <tt>$csinput</tt>)</dt>
   <dd>
     <p>This variable is used in <tt><a href="D.html#D_din">din</a></tt> typemaps and is replaced by the expression which is to be passed to C/C++.</p>
     <p>For example, this input</p>
@@ -214,7 +214,7 @@ void foo(SomeClass arg) {
   example_im.foo(SomeClass.getCPointer(arg));
 }</pre></div></dd>
 
-  <dt id="D_imcall"><tt>$imcall</tt> and <tt>$owner</tt> (C#: <tt>$imcall</tt>)</dt>
+  <dt><a name="D_imcall"></a><tt>$imcall</tt> and <tt>$owner</tt> (C#: <tt>$imcall</tt>)</dt>
   <dd>
     <p>These variables are used in <tt><a href="D.html#D_dout">dout</a></tt> typemaps. <tt>$imcall</tt> contains the call to the intermediary module which provides the value to be used, and <tt>$owner</tt> signals if the caller is responsible for managing the object lifetime (that is, if the called method is a constructor or has been marked via <tt>%newobject</tt>).</p>
     <p>Consider the following example:</p>
@@ -243,7 +243,7 @@ SomeClass bar() {
   </dd>
 
   <dt><tt>$dcall</tt> and <tt>$winput</tt> (C#: <tt>$cscall</tt>, <tt>$iminput</tt>)</dt>
-  <dd id="D_dpcall"><p>These variables are used in the director-specific typemaps <a href="D.html#D_ddirectorinout"><tt>ddirectorin</tt></a> and <a href="D.html#D_ddirectorinout"><tt>ddirectorout</tt></a>. They are more or less the reverse of the <tt>$imcall</tt> and <tt>$dinput</tt> macros: <tt>$dcall</tt> contains the invocation of the D proxy method of which the return value is to be passed back to C++, <tt>$winput</tt> contains the parameter value from C++.</p></dd>
+  <dd><a name="D_dpcall"></a><p>These variables are used in the director-specific typemaps <a href="D.html#D_ddirectorinout"><tt>ddirectorin</tt></a> and <a href="D.html#D_ddirectorinout"><tt>ddirectorout</tt></a>. They are more or less the reverse of the <tt>$imcall</tt> and <tt>$dinput</tt> macros: <tt>$dcall</tt> contains the invocation of the D proxy method of which the return value is to be passed back to C++, <tt>$winput</tt> contains the parameter value from C++.</p></dd>
 
   <dt><tt>$excode</tt></dt>
   <dd><p>This variable is used in <tt>dout</tt> and <tt>dconstructor</tt> typemaps and is filled with the contents of the <tt>excode</tt> typemap attribute if an exception could be thrown from the C++ side. See the <a href="CSharp.html#CSharp_exceptions">C# documentation</a> for details.</p></dd>
@@ -263,7 +263,7 @@ SomeClass bar() {
 </pre></div>
   </dd>
 
-  <dt id="D_importtype"><tt>$importtype(SomeDType)</tt></dt>
+  <dt><a name="D_importtype"></a><tt>$importtype(SomeDType)</tt></dt>
   <dd>
     <p>This macro is used in the <tt>dimports</tt> typemap if a dependency on another D type generated by SWIG is added by a custom typemap.</p>
     <p>Consider the following code snippet:</p>
diff --git a/Doc/Manual/Introduction.html b/Doc/Manual/Introduction.html
index 02a41169a..e0dd3c044 100644
--- a/Doc/Manual/Introduction.html
+++ b/Doc/Manual/Introduction.html
@@ -334,7 +334,7 @@ major features include:
 </ul>
 
 <p>
-Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html">C++11</a> section.
+Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html#CPlusPlus11">C++11</a> section.
 </p>
 
 <p>
diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html
index c33c1c16c..b6885b94f 100644
--- a/Doc/Manual/Java.html
+++ b/Doc/Manual/Java.html
@@ -213,7 +213,7 @@ The Java module requires your system to support shared libraries and dynamic loa
 This is the commonly used method to load JNI code so your system will more than likely support this.</p>
 
 <p>
-Android uses Java JNI and also works with SWIG. Please read the <a href="Android.html">Android chapter</a> in conjunction with this one if you are targeting Android.
+Android uses Java JNI and also works with SWIG. Please read the <a href="Android.html#Android">Android chapter</a> in conjunction with this one if you are targeting Android.
 </p>
 
 <H3><a name="Java_running_swig"></a>25.2.1 Running SWIG</H3>
@@ -5969,7 +5969,7 @@ Again this is the same that is in "<tt>java.swg</tt>", barring the method modifi
 </p>
 
 <p>
-When using <a href="Modules.html">multiple modules</a> or the <a href="#Java_namespaces">nspace feature</a> it is common to invoke SWIG with a different <tt>-package</tt>
+When using <a href="Modules.html#Modules">multiple modules</a> or the <a href="#Java_namespaces">nspace feature</a> it is common to invoke SWIG with a different <tt>-package</tt>
 command line option for each module.
 However, by default the generated code may not compile if 
 generated classes in one package use generated classes in another package.
diff --git a/Doc/Manual/Makefile b/Doc/Manual/Makefile
index 893b4a05d..d7011db06 100644
--- a/Doc/Manual/Makefile
+++ b/Doc/Manual/Makefile
@@ -9,7 +9,7 @@
 # validation.
 #
 # Additional html validation can be done using the validate target.
-# Additional link checking can be done using the linkchecker target.
+# Additional link checking can be done using the linkchecker1 and linkchecker2 target.
 #
 
 # Note the # and " are escaped
@@ -34,6 +34,14 @@ check:
 	tidy -errors --gnu-emacs yes -quiet Sections.html
 	all=`sed '/^#/d' chapters | grep -v CCache.html`; for a in $$all; do tidy -errors --gnu-emacs yes -quiet $$a; done;
 
+# Check for links which don't work including those generated from the individual .html files into SWIGDocumentation.html
+linkchecker:
+	rm -rf linkchecker-tmp
+	mkdir linkchecker-tmp
+	cp SWIGDocumentation.html linkchecker-tmp
+	cp *.png linkchecker-tmp
+	(cd linkchecker-tmp && linkchecker -F text --no-warnings SWIGDocumentation.html)
+
 generate: swightml.book swigpdf.book
 	htmldoc --batch swightml.book || true
 	htmldoc --batch swigpdf.book || true
diff --git a/Doc/Manual/Preface.html b/Doc/Manual/Preface.html
index d17dc229c..23481d751 100644
--- a/Doc/Manual/Preface.html
+++ b/Doc/Manual/Preface.html
@@ -255,7 +255,7 @@ can only fix bugs if we know about them.
 
 
 <p>
-Please see the dedicated <a href="Windows.html">Windows chapter</a> for instructions on installing
+Please see the dedicated <a href="Windows.html#Windows">Windows chapter</a> for instructions on installing
 SWIG on Windows and running the examples. The Windows distribution is
 called swigwin and includes a prebuilt SWIG executable, swig.exe, included in
 the top level directory. Otherwise it is exactly the same as
@@ -332,7 +332,7 @@ be configured with a subset of target languages.
 SWIG used to include a set of runtime libraries for some languages for working
 with multiple modules. These are no longer built during the installation stage.
 However, users can build them just like any wrapper module as described in
-the <a href="Modules.html">Modules chapter</a>.
+the <a href="Modules.html#Modules">Modules chapter</a>.
 The CHANGES file shipped with SWIG in the top level directory
 also lists some examples which build the runtime library.
 </p>
diff --git a/Doc/Manual/Scilab.html b/Doc/Manual/Scilab.html
index cb4a3af90..5a894d587 100644
--- a/Doc/Manual/Scilab.html
+++ b/Doc/Manual/Scilab.html
@@ -321,7 +321,7 @@ $ swig -scilab -help
 
 
 <p>
-SWIG for Scilab provides only a low-level C interface for Scilab (see <a href="Scripting.html">Scripting Languages</a> for the general approach to wrapping).
+SWIG for Scilab provides only a low-level C interface for Scilab (see <a href="Scripting.html#Scripting">Scripting Languages</a> for the general approach to wrapping).
 This means that functions, structs, classes, variables, etc... are interfaced through C functions. These C functions are mapped as Scilab functions.
 There are a few exceptions, such as constants and enumerations, which can be wrapped directly as Scilab variables.
 </p>
diff --git a/Doc/Manual/Typemaps.html b/Doc/Manual/Typemaps.html
index 51fadb095..3d6abf88e 100644
--- a/Doc/Manual/Typemaps.html
+++ b/Doc/Manual/Typemaps.html
@@ -655,7 +655,7 @@ The <a href="http://en.wikipedia.org/wiki/Aspect-oriented_programming#Terminolog
   <li> <b>Aspect</b>: Aspects are the combination of the pointcut and the advice, hence each typemap is an aspect.
 </ul>
 <p>
-SWIG can also be viewed as has having a second set of aspects based around <a href="Customization.html">%feature</a>.
+SWIG can also be viewed as has having a second set of aspects based around <a href="Customization.html#Customization">%feature</a>.
 Features such as <tt>%exception</tt> are also cross-cutting concerns as they encapsulate code that can be used to add logging or exception handling to any function.
 </p>