From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 18:02:23
----- Original Message -----
From: "James Slaughter" <subscriptions_at_[hidden]>
> I prefer to keep a version of boost that I know works with my code within
> project's source tree.
I do the same.
> I'd very much like to be able to refer to that
> location with relative paths, using #include "../libs/boost/etc.hpp".
> Instead, I have to mess around with my project or compiler's environment
> variables and command line options.
The usual thing is to make sure that the parent directory of boost (libs in
your example) is in your compiler's search path, so that #include
<boost/etc.hpp> works. The boost headers need this anyway, since that's how
many of them will get ahold of other boost headers.
> Since the locations used with #include <> are a subset of those matched by
> #include "" (for a more-conforming compiler), it's not clear that using
> bracket notation has any advantage for Boost.
No argument there.
> Regarding Vesa's comments, whilst I've personally never seen a system
> the difference in search times is measurable, I certainly agree with the
> safety aspect - "config.hpp" is a name I'd rather keep out of my system
> include paths.
Uh, yeah. I once had Python pick up the wrong config.h on me :-(
> I'd also like to mention that I've often had to explain to less
> programmers that, "No, boost/xyz.hpp isn't a standard header and although
> some parts of it might be one day, it'll almost certainly have a different
> name". Perhaps the time taken for mortals to understand was what Vesa was
> thinking about.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk