Warren Young wrote:
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.
Such directories do exist on my system (e.g. libpng, libexif, libxml2,
etc). My project name is already lowercase, so that is not an issue.
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.
I don't really want to mandate a specific style to the users of my
library. I just want to use the first style inside my own library, and
right now that doesn't work. So I want to know how to fix that :-)
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.
I think I made it not very clear what is going wrong, so I'll try again.
Suppose that in one of my public headers, I include one of the other
header files, with <libfoo/headerx.h> style. Now when I compile the
library in my src tree, it fails because there is no such header present
in my src tree or system wide (not installed yet). The same for the
examples.
