misc/44148: installworld in 4.7-STABLE does not installIPFilter related header files

Bruce Evans bde at zeta.org.au
Fri Apr 25 12:37:29 PDT 2003


On Fri, 25 Apr 2003, Ruslan Ermilov wrote:

> On Fri, Apr 25, 2003 at 10:43:22PM +1000, Bruce Evans wrote:

> > > On Fri, Apr 25, 2003 at 03:54:32PM +1000, Darren Reed wrote:
> > > > > > Is there any reason to not create a real /usr/include/netinet
> > > > > > and then populate _that_ directory with symbolic links to each
> > > > > > of the files, individually ?  This should preserve the semantics
> > > > > > of what "symlinks" is about.

> > Much as I dislike symlink farms, I think this would work OK (the same
> > as symlinks from individual headers in the top level of /usr/include to
> > various places in the src tree).

> My worries are about the case when someone deletes or adds an
> include file.  If we keep symlinks on a per-directory level,
> there's no problem.  But if we switch to per-header symlinks,
> each time the new header is added, or old header is removed,
> you'll have to re-run "make install" in src/include/.  Other

I would sometimes forget that, but the error would usually be
obvious and harmless -- just a missing header.  The symlink wouldn't
be created or changed nearly as often as the file changes.

> than that, I'd like to keep the consistency in how the kernel
> build does this, and how this does the userland.  Currently,
> kern.pre.mk has -I$S/contrib/ipfilter, and if we add the
> -I/usr/include/contrib/ipfilter, this would work as well.

Ugh, that's a bug in kern.pre.mk.  It also has the hacks
-I${INCLMAGIC}, -I$S/dev and -I$S/contrib/dev/acpica.

> So, I'd like to either do this on a directory level, or kill
> the SHARED=symlinks concept.

I depend on SHARED=symlinks a lot.  However, the number of things that
must be installed manually when not using makeworld is large so another
set of includes wouldn't make much difference.

Bruce


More information about the freebsd-bugs mailing list