Jef Driesen wrote:
If your headers use the libfoo/header.h style, your users must, too.
That's not consistent with your wish above.
Why is that necessary? Isn't the toplevel directory (where the
libfoo/header.h is located) also included, even if the user is using a
<header.h> include style? Or is that only true if the headers are
installed in the standard /usr/include location?
There's nothing preventing one of your users from installing 'libfoo'
other than under one of the standard system include directories. If
someone did that, #include "header.h" will still work, but #include
<libfoo/header.h> will only work if you give a -I flag to the compiler,
giving the parent directory holding 'libfoo'.
This is a usability matter, not a works/doesn't work matter.
I also checked a number of libraries
on my system (cairo, gtk, just to name a few), and none of them has
"header.h" includes. They all have <header.h> includes, with a few
exceptions that have <libfoo/header.h> includes (openssl for instance).
Is there another reason for that?
As Bob said, the C and C++ standards are vague on this matter. You
should try both and see how the compilers you use actually behave.
I maintain a free library myself (http://tangentsoft.net/mysql++/), and
what I'm telling you comes from my experience with these very issues.
We dealt with all this stuff years ago in MySQL++. We found that using
double quotes for "peer" header includes works reliably across all
compilers we target, where we had problems with angle bracket includes.
MySQL++ targets several Windows compilers, which may be relevant here.
If your library will live a more sheltered existence, you might get
away with angle brackets.
