WIP: automatic discovery and build of tests and examples

[GPMueller]

Not yet ready for merging

• Closes #72

The goal of this PR is to bring this feature far enough that at least a few boost libraries can be built including tests and examples and that there be some reasonable way of executing the tests. GLFW will be another case to try this on.

• [x] implement folder discovery
• [x] ability to build tests
• [x] handle dependencies of tests
• [x] ability to build examples
• [x] (de-)activation of building test/example executables via CLI flags, correctly decide if there are any tests to be built
• [x] distinguish between immediate and recursive discovery/build of tests and examples
• [ ] better dependency graph dotfiles (the tests and examples would clutter the main graph, they should be shown separately)
• [x] documentation
• [x] unit tests

[codecov[bot]]

Codecov Report

Merging #73 into master will decrease coverage by 0.63%. The diff coverage is 81.04%.

@@            Coverage Diff             @@
##           master      #73      +/-   ##
==========================================
- Coverage   81.07%   80.43%   -0.64%     
==========================================
  Files          12       12              
  Lines         983     1094     +111     
==========================================
+ Hits          797      880      +83     
- Misses        186      214      +28

Impacted Files	Coverage Δ
clang_build/clang_build.py	71.28% <100%> (+2.63%)	:arrow_up:
clang_build/io_tools.py	100% <100%> (ø)	:arrow_up:
clang_build/dependency_tools.py	70.45% <100%> (+6.56%)	:arrow_up:
clang_build/project.py	66.11% <29.03%> (-5.72%)	:arrow_down:
clang_build/target.py	89.96% <92.13%> (-0.12%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 88f833d...cfd0ca1. Read the comment docs.

[NOhs]

Can't we already have tests, if we group them in a test folder? Aren't tests basically normal targets?

[GPMueller]

In #72 I describe how I would expect the feature to work. The point would be to not have to manually specify tests and examples targets. For small projects this could eliminate the need to have a configuration file. Further, most tests and examples have almost identical content, as they should test the same library, and this can become especially annoying when one wants to define many test executables.

Also, this feature would allow building (maybe later also running?) tests recursively for all targets and their dependencies using the --test-recursive flag (and analogous for examples).

One issue that I ran into is the linking of shared library targets, since they are not placed into the test or example binary directories. So executing the tests and examples only works out of the box for static libraries (see also #25).

[GPMueller]

Closing this PR.

The implementation on this PR is unsuitable for proper usage. The tests/examples might not only depend on the given target itself, but also on other libraries, potentially from a different subproject. This means that tests/examples dependencies need to be resolved after the creation of the full dependency graph.

The build stage improvements described in issue #64 should be implemented first, and a new version of this feature should be implemented.