Credit Andrea with Windows.tex changes based on reading updates in CV manual

[goodguy/cin-manual-latex.git] / parts / Developer.tex

diff --git a/parts/Developer.tex b/parts/Developer.tex
index ca0889edcf695bd38474a79cebb705c6db48eec7..34d355f38c0ba780867b0f6c97199225379028be 100644 (file)
--- a/parts/Developer.tex
+++ b/parts/Developer.tex
@@ -20,7 +20,7 @@ So, an example of what happens in 4 steps for a single-user build would be as fo
 
 \begin{enumerate}[nosep]
        \item unpack/patch source code: \\
-       \texttt{git clone --depth 1 ``git:/{\dots}/target'' cinelerra5} \\
+       \texttt{git clone -{}-depth 1 ``git:/{\dots}/target'' cinelerra5} \\
        \texttt{./autogen.sh}
        \item configure build:\\
        \texttt{./configure --with-single-user}
@@ -227,6 +227,7 @@ Optional Features:
   --enable-openjpeg       build openjpeg (auto)
   --enable-libogg         build libogg (auto)
   --enable-libsndfile     build libsndfile (auto)
+  --enable-libsvtav1      build libsvtav1 (no)
   --enable-libtheora      build libtheora (auto)
   --enable-libuuid        build libuuid (yes)
   --enable-libvorbis      build libvorbis (auto)
@@ -334,12 +335,13 @@ Individual package libraries can be rebuilt, via:
 
 The rule targets create the set of thirdparty packages which are built from local source archive copies of thirdparty source code and patches, if needed.  The build rule set of dependencies allows for compiling multiple thirdparty programs simultaneously using maximum computer resources.  This parallel build speeds up the process considerably.  For example, these are full static build timings on the production build machine (full build includes building all thirdparty programs as well as all of \CGG{}):
 
-\hspace{2em}
-\begin{tabular}{@{}rcr}
-       1 cpu & = & 61 mins\\
-       12 cpus & = & 7.5 mins\\
-       24 cpus & = & 2 mins\\
-\end{tabular}
+\begin{center}
+       \begin{tabular}{@{}lcr}
+               1 cpu & = & 61 mins\\
+               12 cpus & = & 7.5 mins\\
+               24 cpus & = & 2 mins\\
+       \end{tabular}
+\end{center}
 
 \section{Using the very latest Libraries}
 \label{sec:latest_libraries}
@@ -405,14 +407,6 @@ compile; and use binaries that you do not know what they contain since no source
 Look into opencv4/opencv2/core/types.hpp:711;27
 \end{description}
 
-\textbf{webp}
-\begin{description}[noitemsep]
-     \item Status - currently at version 1.1.0
-     \item Problem - requires cmake 3.5 
-     \item Workaround already in use by \CGG{} - leaving out of Ubuntu14, Ubuntu, Centos7
-     \item Your workaround - upgrade on those systems to cmake 3.5
-\end{description}
-
 \textbf{libaom}
 \begin{description}[noitemsep]
      \item Status - currently at version 3.0.0 for older O/S and 3.1.1 for newer O/S
@@ -520,6 +514,10 @@ It is impossible to test everything with valgrind because some things are just t
 deadly. The listing of the memory leaks can be quite voluminous so locating the \textit{LEAK SUMMARY} section
 towards the end of the report is most useful.
 
+Another very useful valgrind run to locate unitialized variables while executing is:
+
+\hspace{2em}\texttt{valgrind -{}-log-file=/tmp/log -{}-tool=memcheck\\
+       -{}-num-callers=32 ./ci}
 
 \section{CFLAGS has -Wall}
 \label{sec:cflags_has_-wall}