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

[Alex J Lennon]

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__0738eb9f13 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? Cheers, Paul -- Alex J Lennon / Director 1 Queensway, Liverpool L22 4RA mobile: +44 (0)7956 668178 This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto