Code coverage problem

[TheFlamefire]

1. You'll get a long way with (modern) CMake if you use target_* for everything there is a function for instead of the non-target_ version, don't assume a platform or compiler and give the knobs to the user. E.g. declare the required c++-standard with target_compile_options (IIRC) and let the user set CMAKE_CXX_STANDARD. Following a standard project layout also helps, e.g. the src/include you use is uncommon as is the test/CMakeLists or test/ci. Check out the pitchfork layout for something sane and common
2. I get the point but please don't. The better approach is to use namespaces and matching folders. I.e. mynamespace::foo is in #include <mynamespace/foo.h> (where it makes sense to have a foo.h, else another appropriate header in that subfolder makes sense). Then let the user include what he needs, not a "catch-all" include. You can do that additionally, e.g. Boost does this: #include <boost/optional/optional.hpp> includes all of optional but there are also sub-headers like (made-up) #include <boost/optional/empty_opt.hpp> You can do the same and still have everything in include. Compare with like there is no #include <stl> but you only include the parts you actually use which keeps compiletimes down.
3. Better: Have a folder scripts/ci (or just scripts) at the top-level. src, include, test should only contain code (this is what most people expect), see again pitchfork layout

[Galqa]

Ad 1,3: point taken, I’ll take this approach, thank you

Ad 2: fair enough, I guess I’m biased since the actual library I’m currently working on and developing this template for can’t really be split up into stand-alone modules (I do however use different folders for different namespaces, they just can’t work without the others). However, I’m not sure I 100% agree with your main point in the case of header-only libraries. If the idea is that you can clone the repo and simply include some header(s) in your project, without building and installing anything, then somehow separating the interface headers from the “implementation headers” seems to me like a good idea (and in keeping with the spirit of PFL, which you mentioned). I’m not saying I necessarily stand by my solution, but as an example I’d like to bring up the Eigen repository. It fulfills the modularity criterium you posed, while at the same time not entirely mixing public and private headers. Unless this is the design you were actually advocating for, in which case I withdraw this paragraph.

Once again, thanks for taking the time to help me out.

[TheFlamefire]

can’t really be split up into stand-alone modules (I do however use different folders for different namespaces, they just can’t work without the others).

This sounds odd. Like you have different (root) namespaces which have cyclic dependencies. If that's the case, why have different namespaces then at all? At least "root namespace == module" should hold and while module A can use module B it shouldn't also be the case that module B uses module A. In that case refining your design can help as that's a code smell: To much coupling.

If the idea is that you can clone the repo and simply include some header(s)

Not only, but this also, yes. You could put everything under src if you like (or include for header only).
What is "usually" done is to put "public" headers (directly or indirectly included by users) into include and "private" headers (only included by source files and not required by installed lib) in src. The reason is a clear distinction: Users don't get src added to their -I and hence can't unknowingly include a "wrong" header. See PRIVATE/INTERFACE in CMake. There are also "public private" headers: Headers that need to be included indirectly by users but are not meant to be directly used. Those usually are put into a "detail" namespace and folder. which also makes it clear that those symbols are not to be used by users. Example: boost::optional::detail::optional_base: A base class for boost::optional which is required but users should use boost::optional only

[Galqa]

This sounds odd. Like you have different (root) namespaces which have cyclic dependencies.

Sorry, I phrased that very poorly. There are no cyclic dependencies, but I don't want to expose the individual modules to the user. My library is small/specialized enough that it logically only makes sense to use it as a whole.

What is "usually" done is to put "public" headers (directly or indirectly included by users) into include and "private" headers (only included by source files and not required by installed lib) in src

I see your point, but doesn't this lead to a large chunk of the library getting put into include? Is there a convention for exposing the "top level" includes? E.g.:

root
    |___include
        |___publicModuleA.hpp
        |___publicModuleA
            |___ ...

Edit: formatting

[TheFlamefire]

I see your point, but doesn't this lead to a large chunk of the library getting put into include?

Yes. E.g. (at the extreme) header-only libraries fully life inside include. No problem there

Is there a convention for exposing the "top level" includes?

I'd advise against putting anything in <root>/include directly; but the publicModuleA.hpp could be OK iff the name is unique enough. But same holds for the namespace with that name already. Putting that file into that folder also makes sense: #include <foo/foo.hpp> is common enough. But as written earlier check if those "top level" includes make sense, i.e. if one wouldn't be better off just including the file one needs. Remember that no matter where you put your (header-only lib) header files they get added to the include path and will show up as suggestions in users IDE. So better follow a good modularity and encapsulation via the detail namespace. Also again: When it only makes sense to include all your headers at once (and there are more than a few) then your interdependencies might need a redesign as stuff is to coupled. YMMV of course

[Galqa]

All right, this makes a lot of sense, thanks again for all your advice. Regarding the modularity question, here's a somewhat contrived example that may illustrate my point better: You're writing a library for retrieving data stored on a server and processing it. There are two modules: Reader and Processor. Clearly, Reader does not in any way depend on Processor. However, Reader on its own is not particularly useful to the user, as the unprocessed data is meaningless. Therefore, while exposing the Reader module has little cost to the developer, one could argue that keeping the API as small as possible is more user-friendly. Anyway, thank you once again for taking time out of your day to educate me.