[yocto] FILES_${PN} packaging and wildcarded exclusions

[Paul Eggleton]

On Tuesday 04 March 2014 11:05:34 Alex J Lennon wrote:
> On 04/03/2014 11:01, Paul Eggleton wrote:
> > Hi Alex,
> > 
> > On Tuesday 04 March 2014 10:10:13 Alex J Lennon wrote:
> >> I'm trying to understand how to cleanly extend FILES${PN} to include
> >> files that are staged and need to be packaged
> >> 
> >> If I start with something like
> >> 
> >> FILES_${PN} += " \
> >> ${libdir}/mono/gac/policy.0.2.Mono.Addins/0.0.0.0__0738eb9f132ed756/* \
> >> ${libdir}/mono/gac/policy.0.2.Mono.Addins.Setup/0.0.0.0__0738eb9f132ed756
> >> /*
> >> \
> >> ${libdir}/mono/gac/policy.0.6.Mono.Addins.CecilReflector/0.0.0.0__0738eb9
> >> f13 2ed756/* \
> >> ${libdir}/mono/gac/policy.0.6.Mono.Addins.Gui/0.0.0.0__0738eb9f132ed756/*
> >> \
> >> <snip/>
> >> 
> >> I seem to be able to clean that up a bit to
> >> 
> >> FILES_${PN} += " \
> >> ${libdir}/mono/gac/*/*/* \
> >> <snip/>
> >> 
> >> What I'd like to do is to be able to represent "all files excepting
> >> files ending with .mdb", for example, as I want to add those to a
> >> ${PN}-dbg package.
> >> 
> >> I was wondering if there's a syntax I can use within FILES_${PN} to
> >> achieve that cleanly?
> > 
> > There isn't I'm afraid - the tools you have available are wildcards and
> > the
> > ordering of PACKAGES, since the first package whose FILES value matches a
> > file will get the file. However, for this specific case this should be
> > just fine - ${PN}-dbg appears before ${PN} in the default value of
> > PACKAGES, so you just need to ensure FILES_${PN}-dbg is extended as
> > needed.
> 
> Oh great, thanks. So as long as I make sure the order of precedence is
> as needed in PACKAGES then the files will go in the right packages.
> 
> I wonder if there's any benefit to allowing regexp in FILES_
> definitions? Or if that's just overcomplicating something that already
> works?

Well, I know the issue of making packaging a bit more flexible has been talked 
about in the past, but I think we'd be reluctant to just add regex support 
unless it's solving something that's hard / impossible with the current 
scheme. The way it works now is already a bit complex for new users so 
increasing the complexity might have the opposite to the desired effect, and of 
course there's compatibility and performance impact to think about.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre