Re: cvs commit: src/lib/libutil _secure_path.c auth.c fparseln.c humanize_number.c login.c login_auth.c login_cap.c login_class.c login_crypt.c login_ok.c login_times.c login_tty.c logout.c logwtmp.c pidfile.c property.c pty.c trimdomain.c uucplock.c

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Mon, 7 Mar 2005 10:53:16 +0100
Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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