Re: [boost] Re: Boost.Build - #include <> vs. ""

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-07-18 15:16:27

From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> williamkempf_at_[hidden] wrote:
[...]
> > 4) <...> headers are ignored as dependencies by some build tools,
> > such as VC++ projects.
>
> Depending on the viewpoint, that may actually be the right thing
> to do.  Isn't upgrading boost in a way similar to upgrading your
> compiler's standard headers to a new version?

Not in my opinion. Boost libraries (and interfaces) change much more
frequently. Boost also grows much faster than the standard library. Upgrading
to a new Boost version is very different from upgrading to a new version of a
standard library implementation.

>  Boost developers
> may have a different answer than people only using boost.
>
> Note that the boost FAQ recommends freezing a version of boost
> for your end-user project's use, therefore updates may be as
> infrequent as a new servicepack for MSVC.

No matter how infrequent updates are, I still prefer that I would not have to
specifically recompile everything, but could instead trust that my tools make
sure that everything that has to be recompiled actually gets recompiled. So,
if there are compilers that ignore <...> dependencies, then I think this is a
very good reason for avoiding the <...> form.

> In general, include handling is a very platform-specific issue,
> so I would not read too much into the standard in this area,
> and rely on experience with actual compilers instead.

I agree. However there is a difference between writing code that agrees with
the standard and writing code that does not agree with the standard. As far as
I understand, the <...> form is specifically intended for standard *headers*
and not for (user) *source files*.

> As a personal preference, I like the look and feel of <...>
> denoting "system" headers, e.g. standard headers, POSIX
> headers, or third party libraries such as boost usually installed
> in a central location on the machine.  Opposed to this are
> "..." headers local to the current project.

My experience and preference is different. At work we have more than 40
libraries, in more or less active use and maintenance, that are not local to
any specific end user project. We will definitely continue to use the "..."
form for those libraries, because we do not consider them to be standard
headers.

We also license some of our libraries to 3rd parties. A library that is 3rd
party to someone is 1st party to someone else. Therefore you should not base
the decision to use a particular include form based on whether a particular
library is 3rd party or 1st party.