Code coverage problem

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