Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Sep 2005 10:32:52 -0700
From:      "David O'Brien" <obrien@freebsd.org>
To:        Max Laier <max@love2party.net>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/conf files kern.pre.mk
Message-ID:  <20050911173252.GB77440@dragon.NUXI.org>
In-Reply-To: <200509111601.58876.max@love2party.net>
References:  <200509110204.j8B244i7094193@repoman.freebsd.org> <200509111601.58876.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 11, 2005 at 04:01:41PM +0200, Max Laier wrote:
> On Sunday 11 September 2005 04:04, David E. O'Brien wrote:
> > obrien      2005-09-11 02:04:04 UTC
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     sys/conf             files kern.pre.mk
> >   Log:
> >   Don't pollute the entire kernel build with -I$S/contrib/pf.
> >
> >   Revision  Changes    Path
> >   1.1045    +32 -16    src/sys/conf/files
> 
> These changes didn't really improve the readability of conf/files.

Since when was the readability of conf/files a goal?  If it were we
would fix config(8) so the first 100 or so lines was readable.
conf/files is seldomly changed or read.

> I don't understand in what way a global -I "pollutes" the kernel build.
...
> Unless you can give some reasoning why this -I is such a bad thing, I'd like 
> to see this reverted in order to keep conf/files clean(er) - thanks.

One reason is that we are open to conflicts in header names.
Another is the output from doing a compile is too cluttered, and this
helps quite a bit.
Another is BSD convention is to use a complete include path from
/usr/src/sys.  We don't put
-I$S/dev/{acc,acpica,advansys,aha,ahb,aic,aic7xxx,amd,amr,an,arcmsr,arl,asr,ata,ath,atkbdc,auxio,awi,bfe,bge,bktr,buslogic,cardbus,ciss,cm,cnw,cnw,cp,cs,ct,ctau,cx,cx,cy,dcons,dec,digi,dpt,drm,ed,eisa,em,en,ep,esp,ex,exca,fatm,fb,fdc,fe,firewire,fxp,gem,gfb,hatm,hfa,hifn,hme,hptmv,hwpmc,ic,ichsmb,ichwd,ida,idt,ie,ieee488,if_ndis,iicbus,iir,ips,ipw,isp,ispfw,iwi,ixgb,joy,kbd,led,lge,lnc,mc146818,mca,mcd,mii,mk48txx,mlx,mly,mpt,mse,my,ncv,nge,nsp,nve,ofw,owi,patm,pbio,pccard,pccbb,pcf,pci,pdq,ppbus,ppc,pst,puc,ral,random,ray,rc,rndtest,rp,sab,safe,sbni,sbsh,scd,si,sio,smbus,sn,snc,sound,sr,stg,sx,sym,syscons,tdfx,tga,trm,twa,twe,tx,txp,uart,ubsec,usb,utopia,vge,vkbd,vx,wi,wl,xe,zs}
in our kernel Makefile and manage to have all those subsystems buildable
and usable.

A bad precedent was started with the initial ACPICA import by adding a
global -I to the kernel build.  He should have preprocessed the files
before importing them.  Just like we do with things imported into
src/contrib (as documented by FREEBSD-upgrade).  But because we had one
-I that affected 130 files, others later felt it was acceptable to add a
global -I for as little as 4 files that was changing the include path for
1000's of files.

It has been said by many that for a kernel component to be imported, even
into contrib, the code has to be editable so we can adapt it our needs.

I can see some argument in having -I$S/contrib, but beyond that files in
sys/contrib should follow the include conventions in the rest of the sys
tree.

> We install these include files so there must not be a conflict anyway.

What pf files are installed in /usr/include?

-- 
-- David  (obrien@FreeBSD.org)



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