1 files changed, 51 insertions, 51 deletions
diff --git a/mds/lazymakefiles.txt b/mds/lazymakefiles.txt
index 09e9960..6df821e 100644
--- a/mds/lazymakefiles.txt
+++ b/mds/lazymakefiles.txt
@@ -28,20 +28,20 @@ You are expected to have the makefile open while reading this.
 * I will be explaining some of the more, let’s say, esoteric behaviours
 of make which can get the beginners confused.
 * gnu make variables are considered macros by C/C++ standards. I will
-use the term ``variable'' since it’s what the gnu make documents use.
+use the term "`variable`" since it’s what the gnu make documents use.
 * The makefiles are not supposed to be hands-off. I change bits here and
 there from project to project.
-* The makefile recognizes the following extensions: `.c` and `.cpp`. If
-you use different extensions, change the makefile accordingly.
+* The makefile recognizes the following extensions: `+.c+` and `+.cpp+`.
+If you use different extensions, change the makefile accordingly.
 
 === The Macros
 
-`TARGET` holds the target name. It uses the `?=` assignment operator so
-you can pass it a different value from a script, just in case. There are
-a bunch of varibales that you can assign on the terminal to replace the
-makefile’s defaults. Among those there are some that are first getting a
-default value assigned and then get the `?=` assignemnt operator so you
-can assign them values from the terminal, e.g:
+`+TARGET+` holds the target name. It uses the `+?=+` assignment operator
+so you can pass it a different value from a script, just in case. There
+are a bunch of varibales that you can assign on the terminal to replace
+the makefile’s defaults. Among those there are some that are first
+getting a default value assigned and then get the `+?=+` assignemnt
+operator so you can assign them values from the terminal, e.g:
 
 [source,make]
 ----
@@ -51,46 +51,46 @@ CC?=clang
 
 It looks a bit backwards but there is a reason for that. The reason why
 we need to do that is because those variables are called
-`implicit variables` in gnu make terminology. Implicit variables are
+`+implicit variables+` in gnu make terminology. Implicit variables are
 already defined by your makefile even if you havent defined them so they
 get some special treatment. In order to assign them values from the
-terminal, we first assign them a value and then use the `?=` operator on
-them. We don’t really need to assign the default value here again, but I
-felt like it would be more expressive to assign the default for a second
-time.
-
-Variables `CC_FLAGS`, `CXX_FLAGS` and `LD_FLAGS` have accompanying
-variables, namely `CC_FLAGS_EXTRA`, `CXX_FLAGS_EXTRA` and
-`LD_FLAGS_EXTRA`. The extra ones use the `?=` assignment. The scheme is
-to have the first set to host the invariant options and use the second
-set, to change the options that would need changing between different
-builds, if need be.
-
-The variable `BUILD_MODE` is used for the sanitizer builds of clang.
-`ADDSAN` will build the code with the address sanitizer. `MEMSAN` will
-build the code with memory sanitizer and `UBSAN` will build the code
-with undefined behaviour sanitizers. The build mode will affect all the
-other targets, meaning you will get a dynamically-linked executable in
-debug mode with address sanitizers if you assign `MEMSAN` to
-`BUILD_MODE`.
+terminal, we first assign them a value and then use the `+?=+` operator
+on them. We don’t really need to assign the default value here again,
+but I felt like it would be more expressive to assign the default for a
+second time.
+
+Variables `+CC_FLAGS+`, `+CXX_FLAGS+` and `+LD_FLAGS+` have accompanying
+variables, namely `+CC_FLAGS_EXTRA+`, `+CXX_FLAGS_EXTRA+` and
+`+LD_FLAGS_EXTRA+`. The extra ones use the `+?=+` assignment. The scheme
+is to have the first set to host the invariant options and use the
+second set, to change the options that would need changing between
+different builds, if need be.
+
+The variable `+BUILD_MODE+` is used for the sanitizer builds of clang.
+`+ADDSAN+` will build the code with the address sanitizer. `+MEMSAN+`
+will build the code with memory sanitizer and `+UBSAN+` will build the
+code with undefined behaviour sanitizers. The build mode will affect all
+the other targets, meaning you will get a dynamically-linked executable
+in debug mode with address sanitizers if you assign `+MEMSAN+` to
+`+BUILD_MODE+`.
 
 === Targets
 
 ==== default
 
-The default target is `all`. `all` depends on `TARGET`.
+The default target is `+all+`. `+all+` depends on `+TARGET+`.
 
 ==== all
 
-`all` is an aggregate target. calling it will build, or rather, try to
+`+all+` is an aggregate target. calling it will build, or rather, try to
 build everything(given your source-code’s sitation, some targets might
 not make any sense).
 
 ==== depend
 
-`depend` depends on `.depend` which is a file generated by the makefile
-that holds the header dependencies. This is how we are making the
-makefile sensitive to header changes. The file’s contents look like
+`+depend+` depends on `+.depend+` which is a file generated by the
+makefile that holds the header dependencies. This is how we are making
+the makefile sensitive to header changes. The file’s contents look like
 this:
 
 [source,make]
@@ -99,18 +99,18 @@ main.c:main.h
 myfile1.c:myfile1.h myfile2.h
 ----
 
-The inclusion directive is prefixed with a `-`. That’s make lingo for
-ignore-if-error. My shell prompt has a `make -q` part in it so just
-`cd`ing into a folder will generate the `.depend` file for me.Lazy and
-Convinient.
+The inclusion directive is prefixed with a `+-+`. That’s make lingo for
+ignore-if-error. My shell prompt has a `+make -q+` part in it so just
+`+cd+`ing into a folder will generate the `+.depend+` file for me.Lazy
+and Convinient.
 
 ==== Objects
 
 For the objects, there are three sets. You have the normal garden
-variety objects that end in `.o`. You get the debug enabled objects that
-end in `.odbg` and you get the instrumented objectes that are to be used
-for coverage that end in `.ocov`. I made the choice of having three
-distinct sets of objects since I personally sometimes struggle to
+variety objects that end in `+.o+`. You get the debug enabled objects
+that end in `+.odbg+` and you get the instrumented objectes that are to
+be used for coverage that end in `+.ocov+`. I made the choice of having
+three distinct sets of objects since I personally sometimes struggle to
 remember whether the current objects are normal, debug or coverage. This
 way, I don’t need to. That’s the makefile’s problem now.
 
@@ -132,10 +132,10 @@ The instrumented-for-coverage executable, dynaimclly-linked.
 
 ==== cov
 
-The target generates the coverage report. it depend on `runcov` which
-itself, in turn, depends on `$(TARGET)-cov` so if you change `runcov` to
-how your executable should run, cov will handle rebuilding the objects
-and then running and generating the coverage report.
+The target generates the coverage report. it depend on `+runcov+` which
+itself, in turn, depends on `+$(TARGET)-cov+` so if you change
+`+runcov+` to how your executable should run, cov will handle rebuilding
+the objects and then running and generating the coverage report.
 
 ==== covrep
 
@@ -156,14 +156,14 @@ Will try to build your target as an archive, i.e. static library.
 
 ==== TAGS
 
-Depends on the `tags` target, generates a tags file. The tags file
+Depends on the `+tags+` target, generates a tags file. The tags file
 includes tags from the header files included by your source as well.
 
 ==== valgrind
 
-Depends on `$(TARGET)` by default, runs valgrind with
-`--leak-check=yes`. You probably need to change this for the makefile to
-run your executable correctly.
+Depends on `+$(TARGET)+` by default, runs valgrind with
+`+--leak-check=yes+`. You probably need to change this for the makefile
+to run your executable correctly.
 
 ==== format
 
@@ -177,7 +177,7 @@ Builds the target using emscripten and generates a javascript file.
 
 ==== clean and deepclean
 
-`clean` cleans almost everything. `deepclean` depends on `clean`.
+`+clean+` cleans almost everything. `+deepclean+` depends on `+clean+`.
 basically a two level scheme so you can have two different sets of clean
 commands.