\documentclass[handout]{beamer}
\usepackage{pgfpages}\pgfpagesuselayout{4 on 1}[a4paper,landscape,border shrink=5mm]

\usepackage{xmpmulti,multimedia,xspace}
\usepackage[latin1]{inputenc}
\usepackage{tikz}
\usetikzlibrary{shadows}
\usepackage{anyfontsize}
\usepackage{graphicx}
\graphicspath{{./img/} }

%\usetheme{Berlin}
\usetheme{AnnArbor}

\setbeamercovered{invisible}
\setbeamersize{text margin left=7.5mm}
\setbeamersize{text margin right=7.5mm}

%==============================================================================

\begin{document}
\title{C Programming Tools: Part 1}
\subtitle{Building and Using your own Toolkit}
\institute[Imperial]{Dept of Computing, \\
	Imperial College London}
\date{25th May 2017}
\newcommand\RBox[1]{%
%  \tikz\node[draw,rounded corners,align=center,] {#1};%
  \tikz\node[draw,rounded corners,align=center,double copy shadow={opacity=0.3,shadow xshift=1ex,shadow yshift=-0.5ex,left color = brown!40,right color = magenta!80},left color=blue!50,right color=yellow!50 ] {#1};%
}  
\newcommand{\pitem}{\pause \item}
\setbeamerfont{author in head/foot}{size={\fontsize{3pt}{4pt}\selectfont}}
\author[Duncan White \& Evangelos Ververas]
{%
   \texorpdfstring{
        \begin{columns}
            \column{.45\linewidth}
            \centering
            \RBox{Duncan C. White\\
            \href{mailto:d.white@imperial.ac.uk}{d.white@imperial.ac.uk}}
            \column{.45\linewidth}
            \centering
            \RBox{Evangelos Ververas\\
            \href{mailto:e.ververas16@imperial.ac.uk}{e.ververas16@imperial.ac.uk}}
        \end{columns}
        %\vspace{-0.3cm}
        %\begin{columns}
        %  \column{0.3\linewidth}
        %  \raggedleft
        %    \includegraphics[width=0.7cm]{pecemblem}
        %    \vspace{-4.8cm}
        %    \column{0.6\linewidth}
        %    \raggedright
        %    Department of CSE\\[1.1ex]
        %    PEC\\
        %    \vspace{-4.8cm}
        %\end{columns}
   }
   {Duncan White \& Evangelos Ververas}
}

\begin{frame}
\titlepage
\end{frame}

%\section*{Outline}
%\begin{frame}
%\tableofcontents
%\end{frame}

\section{Introduction}
\subsection{Toolkits and Craftsmanship}

\begin{frame}
\large
      \begin{itemize}
      \item
      As programmers, you will learn \alert{many languages} over your career.

      \item
      Hopefully you'll learn something from each language.
      \pause
      But some languages flower briefly and then die, others endure.

      \item
      Right now, you're just learning C.

      \pitem
      C is likely to endure.  It's endured for nearly 40 years already!

      \pitem
      When learning a new language like C, there are \alert{several steps}
      to achieve \alert{basic competence}:

      \begin{itemize}
      \pitem
        Learn syntax.
      \item
        Learn semantics.
      \pitem
        Learn the tricky bits
        eg. \alert{pointers}.
	%and \alert{shallow vs deep copies}.
      \pitem
        Learn the \alert{standard library}.
	%(strcpy(), printf(), qsort(), bsearch()..)}.
      \item
        Learn how to write \alert{multi-module programs}.
      \pitem
        Learn the \alert{idioms} and \alert{best practices}.
      \item
        Learn to avoid the \alert{traps} and \alert{pitfalls}.
      \pitem
        Learn how to write \alert{portable code}.
      \end{itemize}
      \end{itemize}

\end{frame}

\begin{frame}

    \large
    These 4 lectures,
    today and the next three Thursdays,
    answer:
  %we'll show you some of the tools in
  %our toolkit, and more generally convince you that you need to choose
  %tools for your toolkit!
  
    
    \alert{What comes after basic C competence?}

    \begin{itemize}
    \pitem
      \alert{Craftsmanship!}
    \pitem
      Build your own \alert{toolkit} of:
      \begin{itemize}
      \item
      \alert{Useful tools},
      \pitem
      \alert{Useful libraries},
      \pitem
      \alert{Craft skills}.
      \end{itemize}
    \pitem
      To make C programming easier and more productive.
    \pitem
       When necessary: \alert{build your own tools!}
    \pitem
      Core Principle: \alert{Ruthless Automation}.
    \pause
    \item
      Doing something boring and repetitive?
      %especially for the second or third time,
      \alert{Can I save time by automating this?}
    \end{itemize}
\end{frame}

\begin{frame}[plain]
Or, to put that another way:

(As seen on the walkway last week).

%\setbeamercolor{col}{fg=yellow, bg=black}
\begin{beamercolorbox}[wd=1.2\textwidth, ht=1.2\textheight]{col}
\centering
%\vspace{80pt}
\includegraphics[width=0.6\textwidth]{Build.png}
\end{beamercolorbox}

\end{frame}


\subsection{Contents}

\begin{frame}
  Today, we'll cover:
      \begin{itemize}
        \item
          \alert{Programmer's Editors:} Use a single editor well.
        \item
	  \alert{Automating Compilation:} Use make.
        \item
   	  \alert{Multi-Directory Programs and Libraries:} How to lay out
	  programs in multiple directories, a Makefile per directory.
        %\item
	%  \alert{Debugging:} Use a debugger and know it well.
        %\item
        %  Building shortlived \alert{tools on the fly}.
	\end{itemize}
    \pause
    Notes:
    \begin{itemize}
    \item
    I strongly recommend \alert{The Pragmatic Programmer (PP)} book,
    by \alert{Hunt \& Thomas}.
    The woodworking metaphor - and a series of excellent Programming Tips -
    comes from there.

    \pause
    \item
    I also recommend \alert{The Practice of Programming (PoP)} book,
    by \alert{Kernighan \& Pike}.
    %There's some overlap with \alert{The Pragmatic Programmer},
    Both books are brilliant expositions of expert-level
    programming craft.

    \pause
    \item
    There's a tarball of examples associated with each lecture,
    as a shorthand \alert{tarball 01.intlist} refers to the directory
    called {\bf 01.intlist} inside the tarball.
    Each directory contains a README file.
    %describing it.
    \end{itemize}
\end{frame}

\section{Programmer's Editors}
\subsection{Use a Single Editor Well (PP tip 22)}

\begin{frame}
  \begin{itemize}
    \item
	  Hunt \& Thomas write (in Tip 22):
\begin{quote}
The editor should be an extension of your hand;
make sure your editor is configurable,
extensible and programmable.
\end{quote}
    \pitem
    You will spend \alert{years of your life} editing programs.

    \item
    Coding might be 80\% thinking and 20\% typing, but your
    typing must not interfere with your thought process.

    \pitem
    So: Explore a few editors, choose one,
    and \alert{spend time} becoming \alert{expert in it}.

    \item
    That includes: learning \alert{how to plug external tools in}.

    \pitem
    It's more than my life's worth to tell you which editor to use.

    \pitem
    Why? Because programmers are notoriously sectarian when it comes to..
  \end{itemize}
\end{frame}

\begin{frame}[plain]
\setbeamercolor{col}{fg=yellow, bg=black}
\begin{beamercolorbox}[wd=1.0\textwidth, ht=1.0\textheight]{col}
\centering \vspace{70pt}
\includegraphics[width=0.8\textwidth]{editorWars.png}
\end{beamercolorbox}
\end{frame}

\begin{frame}
  \begin{itemize}
    \item
       The leading Programmer's editors are (probably) \alert{vim} and \alert{emacs}:

\includegraphics[width=0.3\textwidth]{vimLogo}
\includegraphics[width=0.3\textwidth]{emacsLogo}

    \pitem IDEs such as \alert{Eclipse} and \alert{CLion}
          provide an editor, an automated compilation system
	  and a debugging environment.
	  If you're going to use an IDE,
          learn how to use it well, and
          how to extend and program it.

     \pitem
     Note that \alert{Hunt \& Thomas} aren't much in favour of
     IDEs.  Neither am I:-)
  \end{itemize}
\end{frame}

\begin{frame}
Actually, it's well known that \alert{Real Programmers use Butterflies}
to edit source code:

%\setbeamercolor{col}{fg=yellow, bg=black}
\begin{beamercolorbox}[wd=1.2\textwidth, ht=1.2\textheight]{col}
%\centering
%\vspace{90pt}
\vspace{70pt}
\includegraphics[width=0.9\textwidth]{real_programmers.png}
\end{beamercolorbox}

\end{frame}

\section{Automatic Compilation}
\subsection{Make (tarball 01.intlist)}

\begin{frame}[fragile]
    When multi-file C programming, eg:
    \par\noindent
    \begin{center}
      \includegraphics<1->[height=4.5cm]{diagram-0.pdf}
    \end{center}
    \par\noindent
    There are many source files:
    \begin{itemize}
      \item Module \alert{intlist} comprising two files (interface \alert{intlist.h} and implementation \alert{intlist.c}) - defining a list-of-integers type.
      \item Separate basic definitions header file \alert{defns.h}.
      \item Test program \alert{testlist.c} that tests intlists.
      \item Main program \alert{avgwordlen.c} that uses intlists.
    \end{itemize}
\end{frame}

\begin{frame}[fragile]
    \begin{itemize}
    \item
    \alert{Dependencies} between the files are vital,
    determined by the \alert{\#include} structure.
    See this via:
\begin{verbatim}
grep '#include' *.[ch] | grep '"'
\end{verbatim}

    \item
    Which gives:
{\small
\begin{verbatim}
intlist.c:#include "intlist.h"
avgwordlen.c:#include "intlist.h"
avgwordlen.c:#include "defns.h"
testlist.c:#include "intlist.h"
\end{verbatim}
}

    \item \alert{intlist.c} includes \alert{intlist.h}
            (to check implementation vs interface).
    \item \alert{avgwordlen.c} includes \alert{intlist.h} (because it uses intlists) and \alert{defns.h}, etc
%   \item \alert{testlist.c} includes \alert{intlist.h}

    \pitem
    {\bf Make} uses such file dependencies,
    encoded in a {\bf Makefile},
    to automatically compile your programs.

    \item
    The Makefile contains dependency rules between
    \alert{target} and \alert{source} files with
    \alert{optional actions} (commands) to generate each
    target from the corresponding sources.
    \end{itemize}

\end{frame}

\begin{frame}[fragile]
    Here's the Makefile:
    %for the multi-module example:
\pause
\small
\begin{verbatim}
CC      = gcc
CFLAGS  = -Wall
BUILD   = testlist avgwordlen
\end{verbatim}

\pause
\begin{verbatim}
all:    $(BUILD)
clean:
        /bin/rm -f $(BUILD) *.o core
\end{verbatim}

\pause
\begin{verbatim}
testlist:       testlist.o intlist.o
avgwordlen:     avgwordlen.o intlist.o
avgwordlen.o:   intlist.h defns.h
testlist.o:     intlist.h
intlist.o:      intlist.h
\end{verbatim}

\begin{itemize}
      \pitem
      Makefiles also contain macros, eg \verb+$(CC)+ which
      C compiler to use, \verb+$(CFLAGS)+ what C compiler flags etc.
      Environment variables become macros too, so \verb+$(HOME)+ refers
      to your home directory.

      \pitem
      Note that Make needs very few explicit dependencies and
      even fewer explicit actions,
      because it already knows that \alert{intlist.o} depends on
      \alert{intlist.c},
      and how to compile \alert{.c} files.
      %onto the corresponding \alert{.o} file.

\end{itemize}

\end{frame}


\begin{frame}[fragile]

\begin{itemize}
      \item
      Effectively, Make sees the more complete compilation rule:
\pause
\begin{verbatim}
intlist.o:         intlist.c intlist.h
        $(CC) $(CFLAGS) -c intlist.c
\end{verbatim}

      \pitem
	This rule declares that \alert{intlist.o} is up
	to date only if it is \alert{newer than intlist.c and intlist.h}.
	If it \alert{doesn't exist} or \alert{is older than either file},
	then the action is triggered - compiling \alert{intlist.c}.
      \pitem
        \alert{make} takes optional target names on the command line
	(defaulting to the first target),
        then performs the \alert{minimum number of actions}
	needed to bring the desired targets \alert{up to date},
	based on the \alert{timestamps} of the target and source files.
	
      \pitem
       For example, if \alert{intlist.h} is altered, you run \alert{make},
       that builds the target \alert{all}, which recursively applies all
       the rules checking timestamps and concludes that...

       \item
       ...\alert{intlist.c},
       \alert{testlist.c} and \alert{avgwordlen.c} need recompiling,
       and then the new \alert{testlist.o} and \alert{avgwordlen.o}
       need relinking against the new \alert{intlist.o}, giving the
       2 executables \alert{testlist} and \alert{avgwordlen}.

%      \pitem
%        Common extra targets include
%	\alert{test}, alert{tar} and \alert{install},
%	as in:
%
%\small
%\begin{verbatim}
%install:        avgwordlen
%        install -m0755 avgwordlen $(HOME)/bin/$(ARCH)
%\end{verbatim}

\end{itemize}

\end{frame}

\begin{frame}[fragile]

\begin{itemize}
      \item
      If, instead, \verb+make+ is run after \alert{intlist.c} is modified,
      it figures out that it needs to recompile \alert{intlist.c},
      and relink both executables against the
      new \alert{intlist.o}.

      \pitem
      If, instead, \verb+make+ is run after nothing is modified,
      it figures out that nothing needs to be done.
      This \alert{parsimonious} property of Make is its best feature!

      \pitem
      It's easy to auto-generate Makefiles for
      single directory C projects containing a single main program and
      any number of modules -
      see tarball {\bf 02.c-mfbuild} and {\bf 03.perl-mfbuild} for two
      attempts.

      \pitem Summary: \alert{Always use make,} or some similar tool.
      Keep your Makefile dependencies up to date, optionally auto-generating
      your Makefiles.

      \item
      Google \alert{make tutorial} for more info.

      \pitem
      There are alternatives (or frontends) to Make, for example \alert{Cmake}
      and the Gnu \alert{autoconf} system, these
      generate \alert{Makefiles} automatically,
      and scale well.
      %automatically generating a Makefile per subdirectory.

\end{itemize}

\end{frame}

\subsection{Multi-directory Projects (tarball 04.intlist-with-lib)}

\begin{frame}[fragile]
\begin{itemize}
  \item
  As a C project gets larger, you may wish to break it into several
  sub-directories.

  \pitem
  Core concept: each sub-directory contains:
  \begin{itemize}
    \item
    One or more \alert{modules} (each a paired .c and .h file as usual).
    \item
    Along with any associated test programs. 
    \item
    Plus a Makefile that compiles all the .c files, builds all the test
    programs, and builds a \alert{library} containing the \alert{.o}
    files belonging to those modules.
  \end{itemize}

  \pitem
  Let's split our existing intlist and avgwordlen directory up.

  \item
  What to split?
  \pause
  The intlist module is:
    \begin{itemize}
    \item
    Logically separate.
    \item
    Reusable - whenever we want a list of integers.
    \item
    Depends on only the standard library.
    \end{itemize}

  \item
  That is, it's \alert{highly cohesive}.

  \item
  So: it's perfect for splitting out into a library sub-directory.

  \item
  In tarball directory \alert{04.intlist-with-lib}, you'll see
  what we have done to achieve this.

\end{itemize}
\end{frame}

\begin{frame}[fragile]
\begin{itemize}
  \item
  There's a separate \alert{lib} sub-directory, let's explore it first:
  
  \item
  \alert{lib} contains
  intlist.c, intlist.h, testlist.c and it's own Makefile.

  \item
  \alert{lib/Makefile} builds two core targets:
  \begin{itemize}
    \item
    The executable \alert{testlist}.
    \item
    The library \alert{libintlist.a} containing intlist.o.
  \end{itemize}
  \pitem
  The new parts of that Makefile are:
\begin{verbatim}
LIB     =       libintlist.a
LIBOBJS =       intlist.o
BUILD   =       testlist $(LIB)
...
$(LIB):         $(LIBOBJS)
        ar rc $(LIB) $(LIBOBJS)
        ranlib $(LIB)
\end{verbatim}

\pitem
In BUILD, I've added \verb+$(LIB)+ as an extra target to build.

\item
The \verb+$(LIB)+ rule says that \verb+$(LIB)+ depends on \verb+$(LIBOBJS)+,
i.e. \verb+libintlist.a+ depends on \verb+intlist.o+, and that the action invokes 
\alert{ar} and \alert{ranlib} - tools that build library files.

\end{itemize}
\end{frame}

\begin{frame}[fragile]
\begin{itemize}
\item
The top-level directory contains \alert{avgwordlen.c} and \alert{defns.h},
and a Makefile, containing the following new parts:
\begin{verbatim}
CFLAGS  =       -Wall -Ilib
LDLIBS  =       -Llib -lintlist
BUILD   =       libs avgwordlen
\end{verbatim}

\pitem
In CFLAGS, \verb+-Ilib+ tells the C compiler to search for include files in
the lib directory.

\pitem
In LDLIBS, \verb+-Llib+ tells the linker to search for libraries in the lib directory, and \verb+-lintlist+ links the intlist library in.

\pitem
In BUILD, I've added \alert{libs} before \alert{avgwordlen}.
Later down the main Makefile, we see a rule to make \alert{libs}:
\begin{verbatim}
libs:
        cd lib; make
\end{verbatim}

\pitem
This new \alert{always run} rule tricks Make, with it's
single directory view of the world, into first building in the
lib sub-directory, before building in the current directory.

\end{itemize}
\end{frame}

\subsection{Multi-directory Projects (tarball 05.libintlist)}

\begin{frame}[fragile]
\begin{itemize}
\item
You'll also notice the new target:
\begin{verbatim}
spotless:       clean
        cd lib; make clean
\end{verbatim}

\pitem
I chose a separate \alert{spotless} target,
because
in my head, \verb+make spotless+ cleans more thoroughly than \verb+make clean+.

\pitem
In tarball \alert{05.libintlist} and \alert{06.avgwordlen-only},
you'll see how to split the intlist module out completely from the
avgwordlen application that uses intlists.

\item
In brief: \alert{05.libintlist} contains only the files from
the \alert{lib} directory.

\pitem
It's Makefile adds a new \alert{install} target to install the library into
your \verb+~/c-tools/lib/x86_64+ directory,
and install intlist.h into \verb+~/c-tools/include+.

\pitem
After running \verb+make install+ in \alert{05.libintlist}, your
\verb+~/c-tools+ library permanently contains the intlist ADT, for you to
reuse whenever you like - as shown in \alert{06.avgwordlen-only}.

\pitem
Left for you to work through!

\end{itemize}
\end{frame}
\end{document}
