Namespace and source location rationalization [4]

[halfflat]

Addresses part of Issue #98.

As a prelude to making an install target for Arbor with appropriate paths etc., we need to split out public includes from private includes, and ideally ensure a clean separation between library sub-units within the source tree. This should be coupled with the rationalization of namespace usage within Arbor, so that it is straightforward to find the code implementing a feature living in a sub-namespace foo in a correspondingly named subdirectory in the code base.

There is an existing sketch of a proposal on the wiki.

[halfflat]

There is a strong case to be made that we should limit as much as possible the use of nested namespaces, especially in public interfaces.

See, for example:

• C++ P0816
• Abseil Tip of the Week 130

[bcumming]

If we split the source/header paths into a front end path and back end path, then I think the directory structure of each should match as closely as possible.

For example, if the front end places all cell-type specific headers in arbor/cell_types, then all the cell-type specific headers and source should be in arbor/cell_types in the back end, not seperate paths for each cell type.

By splitting the source front/back, we do introduce additional maintenance burden and mental overload in finding files.

[bcumming]

I understand the motivation for seperating the front end headers, and only installing them, but it will make development of the code more difficult.

[halfflat]

If we make sure our example sources only have the public headers in their include paths, we should be able to catch at build time any instances where we forget to put a necessarily public header in the correct directory.

[halfflat]

While there is room for more internal clean up, the public interfaces and namespaces have been rectified and public headers for all but out-of-tree mechanism builds have been separated, as a result of the installable target work, PRs #506, #518 , #531.