[oe] [RFC] do we really need all OVERRIDES in FILESPATH?

[Richard Purdie]

On Mon, 2010-10-18 at 09:21 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 17-10-10 23:15, Martin Jansa wrote:
> > Currently
> > bitbake -e -b xserver-xorg-conf_0.1.bb | grep ^FILESPATH= | sed "s/:/\n/g" | wc -l
> > shows 65 directories where file:// from SRC_URI can be found.
> > 
> > base_do_unpack is looking for first directory where requested file
> > exists. Most files are IMHO found in FILESPATHPKG PN, files or P
> > (without an override used)
> > 
> > Number of directories tried before
> > PN:    38
> > files: 51
> > P:     25
> > 
> > I see many recipes really using that MACHINE or DISTRO is in FILESPATH,
> > few users of TARGET_ARCH and quick find/grep doesn't show any users of 
> > other OVERRIDES in FILESPATH.
> > 
> > BTW: ie initscripts have initscripts/files/arm/alignment.sh but that's only
> > alignment.sh and SRC_URI_append_arm = " file://alignment.sh" would work
> > ok even without arm in FILESPATH.
> > 
> > What about using only ${TARGET_ARCH}:${DISTRO}:${MACHINE} in FILESPATH
> > instead all OVERRIDES?
> 
> At least I additionally need BASE_PACKAGE_ARCH and SOC_FAMILY in it and
> sometimes libc-$LIBC.

I have to admit, the structure of FILESPATH is a little unwieldy to me.
I'd propose that we should have a small set of defaults like ${BPN} and
${BPN}-${PV} and if any recipe wants more than this, it should have a
variable it can append a list to.

I'd also suggest "files" should probably be deprecated in favour of BPN.

It becomes obvious how horrible the current structure is when you try
and use .bbappend and need to add some extra directory to the search
path.

Cheers,

Richard