Fix basic cmake example
Compare changes
<div class="toc"><ul class="toc-item"><li><span><a href="#Library-and-program" data-toc-modified-id="Library-and-program-1">Library and program</a></span><ul class="toc-item"><li><span><a href="#Static-and-shared-libraries" data-toc-modified-id="Static-and-shared-libraries-1.1">Static and shared libraries</a></span></li></ul></li><li><span><a href="#Source-file" data-toc-modified-id="Source-file-2">Source file</a></span><ul class="toc-item"><li><span><a href="#Compilation-of-Hello-world!" data-toc-modified-id="Compilation-of-Hello-world!-2.1">Compilation of <em>Hello world!</em></a></span></li><li><span><a href="#Source-files-extensions" data-toc-modified-id="Source-files-extensions-2.2">Source files extensions</a></span></li><li><span><a href="#Expanding-our-hello-program-with-two-source-files:-one-for-main,-one-for-the-function" data-toc-modified-id="Expanding-our-hello-program-with-two-source-files:-one-for-main,-one-for-the-function-2.3">Expanding our hello program with two source files: one for main, one for the function</a></span></li></ul></li><li><span><a href="#Header-file" data-toc-modified-id="Header-file-3">Header file</a></span><ul class="toc-item"><li><span><a href="#Header-location" data-toc-modified-id="Header-location-3.1">Header location</a></span></li><li><span><a href="#""--or-<>?" data-toc-modified-id="""--or-<>?-3.2"><code>""</code> or <code><></code>?</a></span></li><li><span><a href="#Header-guards" data-toc-modified-id="Header-guards-3.3">Header guards</a></span></li><li><span><a href="#Header-files-extensions" data-toc-modified-id="Header-files-extensions-3.4">Header files extensions</a></span><ul class="toc-item"><li><span><a href="#My-personal-convention" data-toc-modified-id="My-personal-convention-3.4.1">My personal convention</a></span></li></ul></li></ul></li><li><span><a href="#Why-a-build-system:-very-basic-CMake-demonstration" data-toc-modified-id="Why-a-build-system:-very-basic-CMake-demonstration-4">Why a build system: very basic CMake demonstration</a></span></li><li><span><a href="#Where-should-the-headers-be-included?" data-toc-modified-id="Where-should-the-headers-be-included?-5">Where should the headers be included?</a></span></li><li><span><a href="#Forward-declaration" data-toc-modified-id="Forward-declaration-6">Forward declaration</a></span></li></ul></div>
* A **static** library, usually with a **.a** extension, is actually included directly into any executable that requires it. The advantage is that you just need the bare executable to run your code: the library is no longer required at runtime. The inconvenient is that the storage space may balloon up rather quickly: each executable will contain the whole library!
* A **shared** library, which extension may vary wildly from one OS to another (**.dylib**, **.so**, **.dll**, etc...), is on the other hand required at runtime by the executable that was built with it. The advantage is that executables are thus much smaller. They are often described on the Web as the way to go; my personal experience with them is however less rosy as each OS handles them differently (noticeably the way to indicate in which location the dynamic libraries should be looked at differ rather wildly...)
```
```
```
```
```
You may imagine working in a single file is not an very common option: it hinders reusability, and it would be cumbersome to navigate in a file with thousands or more lines or code (if you're really curious to an extreme case have a look at the amalgamation ([2.28 Mo zip here](https://www.sqlite.org/2020/sqlite-amalgamation-3310100.zip)) of sqlite code, in which all the code is put in a same source file...)
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
In my code, to ensure the first never happen, I have written a [Python script](https://gitlab.inria.fr/MoReFEM/CoreLibrary/MoReFEM/raw/master/Scripts/header_guards.py) which iterates through all the C++ files in my library, identify the header guards of each header file and check they are a mix of the project name and the path of the file. So definitely much more clunky than **#pragma once** ! But as I said the latter is non standard and there are hot discussions about whether it is safe or not for all set-ups (at some point it was complicated to use if there were symbolic or hard links in the project).
```
```
```
```
```
```
The issue with that is that it's not robust at all: either you recompile everything all the time (and let's face it: it's tedious even with our limited number of files...) or you have to keep track of which should be recompiled. For instance if `who-are-you.hpp` is modified all source files include it and must be recompiled, but if it is `hello.hpp` `who_are_you.cpp` is not modified.
```
```
```
```
```
* Each time a source file is modified, only this source file is modified; some relinking for the libraries and executables that depend on it will also occur (linking is the step that glue together the object files and libraries; the term _compilation_ is often - included in this very tutorial - abusively used to encompass both compilation and link phases).
```
```
```
* `#include <string>` is present in `foo.hpp` as it is required to give the information about the type of the prototype to be used. If you do not do that, each time you include `foo.hpp` you would need to include as well `string`; doing so leads to unmaintainable code as you would have to track down all the includes that are required with each include...
```
```
```
```
This is not without cost: obviously in a file where `Bar` is actually needed you will need to include it properly: with just `#include "foo.hpp"` you can't for instance call a method of `Bar`. It is nonetheless a very nice trick to know; there is even an idiom call [Pimpl idiom](https://arne-mertz.de/2019/01/the-pimpl-idiom/) that relies upon forward declaration.