Thank you very much for the detailed answer(s) and comments. My next question would be for some advice where to find more information on topics like
- default splitting policy (settings) - flags as INHIBIT_PACKAGE_DEBUG_SPLIT - etc… May be there is some ‘obvious logic’ in files splits, etc. which would make reading the code easily…. So far, I tried to read the manuals, Yocto book… It looks like those papers are covering well the general ideas and strategies. But as they say - ‘ the devil is in details’, And so far, I have hard time to find info on such details… Once again, thanks for the kind attention to this matter. And my apology that I put the original message within the wrong list. Michael. > On Aug 25, 2014, at 11:46 AM, Khem Raj <[email protected] > <mailto:[email protected]>> wrote: > > On 14-08-25 10:24:57, Mark Hatle wrote: >> First this is the wrong list. The question should have gone to oe-core >> devel, or openembedded-devel lists. (I have CC'd the first) >> >> On 8/21/14, 9:59 PM, [email protected] <mailto:[email protected]> wrote: >>> Hi, >>> I’m trying to write ( and to use ) a recipe which should build a simple >>> .rpm, >>> which contains the /usr/lib/libaffinity.so and a few header files within >>> /usr/include/affinity/* subdir. > > if you install it right then you should get one rpm with library another > one ${PN}-dev which should contain the headers and all debug info will > be split out into a rpm of its own ${PN}-dbg, this is standard > packaging strategy in OE. > > >>> >>> However, it looks like bitbake is trying / “forcing” me to build a >>> ${PN}-dbg >>> package….: > > Yes it will, is there any issue with that ? > > >>> >>> I’m doing the following steps: >>> >>> 1. recipe: >>> “ >>> … >>> inherit cmake pkgconfig >>> >>> PACKAGES = "${PN}" > > overriding PACKAGES will leave some unpackaged files. > >>> FILES_${PN} = "${libdir}/libaffinity.so /usr/include/affinity/*” >>> … > > I would suggest to use standard packaging split if thats not a big > issue. > >>> “ >> >> Just removing '${PN}-dbg' does not inform the system that you do not want >> debug information to be generated. There is a set of standard routines, >> performed after do_install, that will generate the debug information unless >> disabled. >> >> To disable the routines you set: >> >> INHIBIT_PACKAGE_DEBUG_SPLIT = '1' >> INHIBIT_PACKAGE_STRIP = '1' >> >> There are two settings they can be used separately, but in your case you >> likely want both. >> >> INHIBIT_PACKAGE_DEBUG_SPLIT = '1' disables the files in your package from >> being split into run-time and debug components. >> >> INHIBIT_PACKAGE_STRIP = '1' disabled the system from attempting to strip the >> run-time components of debug information. >> >> --Mark >> >>> So, I assume I’ m asking to build only 1 package. >>> >>> 2. During the bitbake processing, as the compilation, build, and >>> installation >>> are over, the files are copied into the ${D} directory, as expected: >>> “ >>> michael@localhost image]$ pwd >>> /home/michael/Devlab/poky/build-atmel/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/affinityng/0.1-r0/image >>> [michael@localhost image]$ cd usr >>> [michael@localhost usr]$ ls -la >>> total 16 >>> drwxr-xr-x. 4 michael michael 4096 Aug 21 19:57 . >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 .. >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 include >>> drwxr-xr-x. 2 michael michael 4096 Aug 21 19:57 lib >>> “ >>> So far, everything as expected in accordance with the Yocto reference. >>> >>> 3. According to the manual reference - "The |do_package| and >>> |do_packagedata| tasks combine to analyze the files found in the |D| >>> <http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-D >>> <http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-D>> >>> directory…”, >>> I would expect that the package would be build. >>> However, the attempt to build is failing. with the error: >>> “… >>> ERROR: QA Issue: affinityng: Files/directories were installed but not >>> shipped >>> /usr/src >>> /usr/lib/.debug >>> /usr/lib/.debug/libaffinity.so >>> /usr/src/debug >>> /usr/src/debug/affinityng >>> /usr/src/debug/affinityng/0.1-r0 >>> /usr/src/debug/affinityng/0.1-r0/kernel >>> … >>> “ >>> >>> 4. Following the reference, I checked the PKGD directory, where the files >>> should >>> be before split…. >>> And I noticed that there is the src directory there, in addition to >>> directories — include and lib — the only ones I was expecting to see there. >>> ( see log below ) . >>> >>> “ >>> /home/michael/Devlab/poky/build-atmel/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/affinityng/0.1-r0/package/usr >>> …. >>> [michael@localhost usr]$ ls -la >>> total 20 >>> drwxr-xr-x. 5 michael michael 4096 Aug 21 19:57 . >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 .. >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 include >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 lib >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 src >>> [michael@localhost usr]$ pwd >>> /home/michael/Devlab/poky/build-atmel/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/affinityng/0.1-r0/package/usr >>> [michael@localhost usr]$ cd src >>> [michael@localhost src]$ ls -la >>> total 12 >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 . >>> drwxr-xr-x. 5 michael michael 4096 Aug 21 19:57 .. >>> drwxr-xr-x. 3 michael michael 4096 Aug 21 19:57 debug >>> [michael@localhost src]$ >>> “ >>> 5. It looks like that as result of package split, the include & lib >>> directories >>> are used properly to build affinityng package, at least it is shown in >>> packages-split properly. >>> But then , the content of the src directory is causing the problem with QA. >>> >>> 6. At the same time, if I ask to build ${PN}-dbg package in addition - both >>> packages are build, no QA complains, and all src/debug/* are going into the >>> -dbg >>> package… >>> >>> I wonder, >>> - why does the src directory appear within PKGD/usr? ( If there is no such >>> directory within the ${D} directory...) >>> - where is the definition for -dbg package is coming from, and is it >>> possible >>> to disable it? >>> >>> May be somebody have the answer or suggestion what to check next…. >>> >>> Thanks for a kind attention to the matter. >>> >>> Have a great day, >>> Michael. >>> >>> >>> >> >> -- >> _______________________________________________ >> bitbake-devel mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.openembedded.org/mailman/listinfo/bitbake-devel > -- > _______________________________________________ > bitbake-devel mailing list > [email protected] > <mailto:[email protected]> > http://lists.openembedded.org/mailman/listinfo/bitbake-devel > <http://lists.openembedded.org/mailman/listinfo/bitbake-devel>
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
