From: Nicolai Josuttis (nicolai.josuttis_at_[hidden])
Date: 2000-01-04 17:35:34
Greg Colvin wrote:
> From: Nicolai Josuttis <nicolai.josuttis_at_[hidden]>
> > Beman Dawes wrote:
> > > One additional thought about #includes. Lots of boost code writes
> > > them like this: #include <boost/operators.hpp>. It would be nice to
> > > turn that into a hyperlink, perhaps keying on "boost/" after an
> > > include.
> > >
> > Hmmm, that's difficult!
> > First, do we have a policy to put all headers in a subdirectory boost?
> > So far, I don't do it with my boost sources.
> > Sorry for not knowing this.
> > Second, as "..." usualy looks for local files and <...> for standard
> That was my belief too, and I argued that our policy should be for
> boost files to use
> #include "boost/operators.hpp"
> but the C and C++ standards hint at little and promise nothing about how
> "" and <> differ, and I'm told the "search local" vs. <search system>
> convention is not so universal as I thought. But why we always use
> #include <boost/operators.hpp>
> I don't recall.
Hmm, I don't remember this discussion but I am quite sure
that "..." differs from <...> only in the fact that in addition it
searches in the local directory before using the path of <...>.
The design idea is that "..." is for something local
(under development) and <...> is for something stable and installed.
As we talk about more than one path it is difficult to
take/find the right path for a <...> include.
For "..." the guess is that it is really local.
So, if we try to handle <...> I see the following possibility:
1) Let the script find the correct path
2) Allow the user to specify the correct path
Both is difficult because for different files different paths might
be used. In addition, this might go beyond a (simple) awk script.
3) Don't handle <...> this way.
As I do now
4) Allow to pass an option to switch some certain paths or include
files to a certain path. Thus, e.g. by passing something like
to allow special settings and handlings.
And may be an additional script could later process and pass these
options to the awk script.
If nobody has another idea I'll try to implement something
like 4 (proposals are welcome, but note that the only way to
pass an argument to awk is via the -v option AFAIK).
> > files and as I usually don't know the path to standard files
> > this policy was a good way to handle all local stuff, which should be under
> > investigation when writing programs.
> > If I add the same for boost, where should I consider boost file
> > to be in relation to the original file?
> > - same directory?
> > - subdirectory boost
> > - sibling directory boost
> > - ...
> Good question. As is stands you would need to get your hands on the
> system include path from the environment and go searching for boost.
This definitely goes beyond an awk script
(although it might be possible because you can do ANYTHING with awk :-)
> > In any way, this would be a special hack for boost.
> > So far, the script is generic for any C++ code.
> > Is it worth it?
> If you can get your hands on the include path in a portable way then
> it remains generic. I don't know if awk allows this or not.
-- Nicolai M. Josuttis http://www.josuttis.de/ Solutions in Time mailto:solutions_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk