Jef Driesen wrote:
I don't really want to mandate a specific style to the users of my
library.
[snip]
Suppose that in one of my public headers, I include one of the other
header files, with <libfoo/headerx.h> style.
If your headers use the libfoo/header.h style, your users must, too.
That's not consistent with your wish above.
To allow your users choice in the matter, your public headers should use
this style when pulling in other headers from the same project:
#include "my-other-header.h"
The use of "" instead of <> tells the compiler to look in the current
directory before going through the list of other possible directories.
This is exactly what you want when you don't know where the user has
installed the headers. A side benefit is that it protects you if there
is a my-other-header.h on the system in one of the other directories in
the include path; the compiler will always use the right one.
The code style you use in your examples is another matter entirely. One
way to fix it would be to make a symlink in the examples directory:
$ cd examples
$ ln -s ../src libfoo
If you're using a VCS that understands symlinks (e.g. svn, but not cvs)
and always target POSIX systems, you can keep the symlink in the
repository, and add it to EXTRA_DIST so it gets put in the tarball.
If you're targeting POSIX only but can't store the symlink in the
repository, you can create it in examples/Makefile.am:
all-local:
ln -s ../src libfoo
(It might have to be moved up to the top-level Makefile.am to have the
operations go in the right order.)
If you have to deploy on non-POSIX systems, then you have no choice but
to reorganize your source tree, as Ralf suggested.
