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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto