On Mon, 7 Mar 2005 10:53:16 +0100
Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
> On Fri, Mar 04, 2005 at 08:55:27AM -0800, Chris Pressey wrote:
> > On Fri, 4 Mar 2005 14:39:42 +0100
> > Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
> >
> > > On Thu, Mar 03, 2005 at 08:31:11PM -0800, Chris Pressey wrote:
> > > > - libutil.h and login_cap.h are located in this directory, so
> > > > don't
> > > > treat them as system-wide headers. (<libutil.h> ->
> > > > "libutil.h")
> > >
> > > I object this part. The headers are installed in /usr/include and
> > > it destroys consistence.
> >
> > When you're building the library, don't you want to use the local
> > header (which will be up-to-date with the library sources) instead
> > of the one in /usr/include (which might be stale?)
>
> They are installed first as part of buildworld.
What about when a programmer is simply developing in the libutil
directory?
> And they should be included first if you have -I. -I${.CURDIR} in the
> CFLAGS.
That seems like a circuitous and illogical way to achieve the goal,
though.
In my mind, it comes down to there being an ontological, rather than
mechanical, difference between system-wide include files <foo.h> and
local include files "foo.h"; from the point of view of other programs,
yes, libutil.h is a system-wide include file, but from the point of view
of libutil itself, libutil.h is local, and should be referenced as such.
-Chris