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