Jef Driesen wrote:
I noticed it is common practice to install the public headers to
$includedir/libfoo
I don't think I've ever seen a 'lib' prefix on a header file directory.
$includedir/foo is far more common.
It's also common for 'foo' to be a diminutive, lowercased version of the
project's full name. For example, Gnome's GTK+ headers are typically
installed in gtk/*.h. It would go against convention if they were
instead installed in GTK+/*.h.
CFLAGS=-I${includedir}
#include <libfoo/header.h>
or
CFLAGS=-I${includedir}/libfoo
#include <header.h>
I think the first one is preferable (but I might be wrong),
It's purely a matter of preference. You're right to segregate the
headers, but a project shouldn't mandate one #include/-I style over another.
if I use the
<libfoo/header.h> style include in my project, it fails to build
anything, because the header files are not installed yet and thus can't
be found.
This is why you don't want to bake such policy into the design of your
library. Your examples can use #include <header.h>, with -I../src.
Your users can use <foo/header.h> with no -I if foo is under a system
include directory, or <header.h> with an explicit -I otherwise.
