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

[Frans Meulenbroeks]

2010/10/18 Richard Purdie <rpurdie at rpsys.net>:
> 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.

I'm all in favour of that but....
- we currently have 724 files directories (so this is some work)
- I'm not fully sure this will work for packages that have recipes
with different names (e.g. alsa), ofc we could rework these and add a
FILESPATHPKG
- not sure if removing files completely will not cause any problems
for the top level files dir (which contains some static device tables
(then again I didn't really found that to be an appropriate place
either)

BTW in my overlay in the top level files folders I also keep my own
busybox config. Not sure how others deal with that, but I can image
that also becomes broken
>
> 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.
>

Agree. Frans.