Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Oct 1998 13:32:39 +0000
From:      dmaddox@scsn.net (Donald J. Maddox)
To:        Mike Smith <mike@smith.net.au>, dmaddox@scsn.net
Cc:        current@FreeBSD.ORG
Subject:   Re: Shouldn't 'make includes' install stand.h?
Message-ID:  <19981004133239.A309@scsn.net>
In-Reply-To: <199810041629.JAA05200@dingo.cdrom.com>; from Mike Smith on Sun, Oct 04, 1998 at 09:29:21AM -0700
References:  <19981004095625.A879@scsn.net> <199810041629.JAA05200@dingo.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 04, 1998 at 09:29:21AM -0700, Mike Smith wrote:
> > While trying to build the new boot loader, it kept failing because
> > stand.h was not found.  To make a long story short, I had previously
> > done a 'make -DCLOBBER includes' in the (apparently mistaken) belief
> > that this was the canonically-accepted way of making sure that I had
> > a clean, up-to-date, and _complete_ set of includes in /usr/include.
> > It appears that /usr/include/stand.h only gets installed when
> > libstand is installed.
> > 
> > Shouldn't a 'make -DCLOBBER includes' result in a _complete_ set
> > of includes?  Are there other includes than stand.h that don't
> > get installed by 'make includes'?
> 
> No.  "Make includes" installs random header files.  libstand.h is 
> installed at the same time libstand is; if you install just the former, 
> you're going to die in the link phase when you can't find the latter.

    'Random header files'?  Ok, if you say so, but so far, the only "standard"
component of /usr/include I've managed to identify as _not_ installed by
'make includes' is stand.h.  This seems counterintuitive to me...

    Your point about installing the header without the lib is valid, but it
seems to me that this is applicable to just about all of the includes, in one
way or another.  Maybe there shouldn't be a 'make includes' target at all?

    I'm not trying to be combative here; this is not a religious issue to
me...  The current behavior just seems to me to violate POLA.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981004133239.A309>