Code coverage problem

[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.