Tino Didriksen <mail_at_[hidden]> writes:

> So I figured I'd try it out on an existing project [...]

Thanks for giving at a go before judging ;-)


> A consequence of library target folders being named libfoo is that #include
> must also use <libfoo/...>. That's a step too far. #include <> implies it's
> a public library [...]

An executable can have public headers. One common case is plugin support
with the header defining the API. A good example of an executable that
comes with headers is GCC.

FWIW, I had the same negative reaction to <libfoo/...> initially (all
our projects now use this naming scheme). It just felt unnatural. But
after a couple of week, I got used to it and now it feels completely
natural. In a way, it makes your "include block" more regular with
clear separation between C/C++ standard library headers, other
library headers, and your project's headers. Here is an example:

#include <errno.h>

#include <vector>
#include <string>
#include <memory>
#include <utility>

#include <libbutl/url.hxx>
#include <libbutl/path.hxx>
#include <libbutl/process.hxx>

#include <libbpkg/manifest.hxx>
#include <libbpkg/package-name.hxx>

#include <bdep/git.hxx>
#include <bdep/project.hxx>
#include <bdep/database.hxx>
#include <bdep/diagnostics.hxx>

Finally, the proposed naming scheme makes for a simple rule: all non-
language names (file/directory names, macros, etc) are with the lib
prefix, while all C++ names (namespaces, modules, etc) -- without.