fixed html documentation!
diff --git a/doc/html_generated/benchmarks.html b/doc/html_generated/benchmarks.html
index 32b90cb..9b97c8f 100644
--- a/doc/html_generated/benchmarks.html
+++ b/doc/html_generated/benchmarks.html
@@ -6,16 +6,19 @@
# Compile time benchmarks
The benchmarks are done with [**this**](../../scripts/bench/bench.py) script using CMake. There are 2 benchmarking scenarios:
+
- [the cost of including the header](#cost-of-including-the-header)
- [the cost of an assertion macro](#cost-of-an-assertion-macro)
Compilers used:
+
- WINDOWS: Microsoft Visual Studio Community 2015 - Version 14.0.25431.01 Update 3
- WINDOWS: gcc 6.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
- LINUX: gcc 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
- LINUX: clang 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 3.6.2) Ubuntu - Target: x86_64-pc-linux-gnu
-Environment used (Intel i7 3770k, 16g RAM)
+Environment used (Intel i7 3770k, 16g RAM):
+
- Windows 7 - on an SSD
- Ubuntu 15.10 in a VirtualBox VM - on a HDD
diff --git a/doc/html_generated/faq.html b/doc/html_generated/faq.html
index 2fb234b..1dc3d75 100644
--- a/doc/html_generated/faq.html
+++ b/doc/html_generated/faq.html
@@ -51,6 +51,7 @@
Using the [**fast**](assertions.html#fast-asserts) asserts in combination with [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) yelds the [**fastest**](benchmarks.html#cost-of-an-assertion-macro) compile times.
There are only 2 drawbacks of this approach:
+
- using fast asserts (40-80% [**faster**](benchmarks.html#cost-of-an-assertion-macro) than ```CHECK(a==b)```) means that there is no ```try/catch``` block in each assert so if an expression throws the whole test case ends.
- defining the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier will result in even [**faster**](benchmarks.html#cost-of-an-assertion-macro) fast asserts (30-80%) at the cost of only one thing: when an assert fails and a debugger is present - the framework will break inside a doctest function so the user will have to go 1 level up in the callstack to see where the actual assert is in the source code.
@@ -68,13 +69,14 @@
### Why are my tests in a static library not getting registered?
-This is a [**common**](https://github.com/google/googletest/blob/master/googletest/docs/V1_7_Primer.html#important-note-for-visual-c-users) [**problem**](https://groups.google.com/forum/#!msg/catch-forum/FV0Qo62DvgY/jxEO6c9_q3kJ) and it affects all modern compilers on all platforms.
+This is a [**common problem**](https://groups.google.com/forum/#!msg/catch-forum/FV0Qo62DvgY/jxEO6c9_q3kJ) and it affects all modern compilers on all platforms.
The problem is that when a static library is being linked to a binary (executable or dll) - only object files from the static library that define a synbol being required from the binary will get pulled in (this is a linker/dependency optimization).
I have created a CMake function that forces every object file from a static library to be linked into a binary target - it is called [**```doctest_force_link_static_lib_in_target()```**](../../examples/exe_with_static_libs/doctest_force_link_static_lib_in_target.cmake). It is unintrusive - no source file gets changed - everything is done with compiler flags per source files. An example project using it can be found [**here**](../../examples/exe_with_static_libs).
It doesn't work in 2 scenarios:
+
- either the target or the library uses a precompiled header - see [**this**](https://github.com/onqtam/doctest/issues/21#issuecomment-247001423) issue for details
- either the target or the library is an imported target (pre-built) and not built within the current cmake tree
diff --git a/doc/markdown/benchmarks.md b/doc/markdown/benchmarks.md
index f594637..5526217 100644
--- a/doc/markdown/benchmarks.md
+++ b/doc/markdown/benchmarks.md
@@ -1,16 +1,19 @@
# Compile time benchmarks
The benchmarks are done with [**this**](../../scripts/bench/bench.py) script using CMake. There are 2 benchmarking scenarios:
+
- [the cost of including the header](#cost-of-including-the-header)
- [the cost of an assertion macro](#cost-of-an-assertion-macro)
Compilers used:
+
- WINDOWS: Microsoft Visual Studio Community 2015 - Version 14.0.25431.01 Update 3
- WINDOWS: gcc 6.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
- LINUX: gcc 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
- LINUX: clang 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 3.6.2) Ubuntu - Target: x86_64-pc-linux-gnu
-Environment used (Intel i7 3770k, 16g RAM)
+Environment used (Intel i7 3770k, 16g RAM):
+
- Windows 7 - on an SSD
- Ubuntu 15.10 in a VirtualBox VM - on a HDD
diff --git a/doc/markdown/contributing.md b/doc/markdown/contributing.md
index 776602e..301eb0a 100644
--- a/doc/markdown/contributing.md
+++ b/doc/markdown/contributing.md
@@ -26,5 +26,6 @@
Testing with compilers different from GCC/Clang/MSVC (and more platforms) is something the project would benefit from.
+---------------
-
+[Home](readme.md#reference)
diff --git a/doc/markdown/faq.md b/doc/markdown/faq.md
index 517b9c4..347943b 100644
--- a/doc/markdown/faq.md
+++ b/doc/markdown/faq.md
@@ -46,6 +46,7 @@
Using the [**fast**](assertions.md#fast-asserts) asserts in combination with [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.md#doctest_config_super_fast_asserts) yelds the [**fastest**](benchmarks.md#cost-of-an-assertion-macro) compile times.
There are only 2 drawbacks of this approach:
+
- using fast asserts (40-80% [**faster**](benchmarks.md#cost-of-an-assertion-macro) than ```CHECK(a==b)```) means that there is no ```try/catch``` block in each assert so if an expression throws the whole test case ends.
- defining the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.md#doctest_config_super_fast_asserts) config identifier will result in even [**faster**](benchmarks.md#cost-of-an-assertion-macro) fast asserts (30-80%) at the cost of only one thing: when an assert fails and a debugger is present - the framework will break inside a doctest function so the user will have to go 1 level up in the callstack to see where the actual assert is in the source code.
@@ -63,13 +64,14 @@
### Why are my tests in a static library not getting registered?
-This is a [**common**](https://github.com/google/googletest/blob/master/googletest/docs/V1_7_Primer.md#important-note-for-visual-c-users) [**problem**](https://groups.google.com/forum/#!msg/catch-forum/FV0Qo62DvgY/jxEO6c9_q3kJ) and it affects all modern compilers on all platforms.
+This is a [**common problem**](https://groups.google.com/forum/#!msg/catch-forum/FV0Qo62DvgY/jxEO6c9_q3kJ) and it affects all modern compilers on all platforms.
The problem is that when a static library is being linked to a binary (executable or dll) - only object files from the static library that define a synbol being required from the binary will get pulled in (this is a linker/dependency optimization).
I have created a CMake function that forces every object file from a static library to be linked into a binary target - it is called [**```doctest_force_link_static_lib_in_target()```**](../../examples/exe_with_static_libs/doctest_force_link_static_lib_in_target.cmake). It is unintrusive - no source file gets changed - everything is done with compiler flags per source files. An example project using it can be found [**here**](../../examples/exe_with_static_libs).
It doesn't work in 2 scenarios:
+
- either the target or the library uses a precompiled header - see [**this**](https://github.com/onqtam/doctest/issues/21#issuecomment-247001423) issue for details
- either the target or the library is an imported target (pre-built) and not built within the current cmake tree