[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Advice on the project structure for a library

From: Warren Young
Subject: Re: Advice on the project structure for a library
Date: Tue, 03 Jun 2008 09:13:34 -0600
User-agent: Thunderbird (Windows/20080421)

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 (, 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]