> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) <di...@cisco.com> wrote: > >>> Are the files present in the image/packages? Maybe it is just the >>> bitbake cache skipping doing work it already did last time. > > If I don’t do the bitbake clean, and just do bitbake again, then yes. > > > But if I do “bitbake -c clean c-mlib” and bitbake again, the is where the > problem.
well its using sstate cache here so when you do clean and rebuild and it notices no changes from previous builds then it is just going to reuse the build artifacts from last builds and not checkout the sources etc. all those tasks will be skipped. why are looking for sources in a build tree ? I ask because if you want to hack on it then I would recommend following devtool workflow. see http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-devtool-in-your-workflow > > Thanks, > —Dinh > > > > > On 10/5/16, 9:30 AM, "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> wrote: > >> On Wed, Oct 05, 2016 at 04:06:25PM +0000, Dinh Nguyen (dinhn) wrote: >>> Many thanks Paul. Your help is greatly appreciated. >>> >>> 1. >>> Like the other responder I would suggest you not set PACKAGES >>> >>> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built >>> as shown below: >>> >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find >>> tmp/deploy | grep >>> c-mlibtmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk >>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk >>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk >>> tmp/deploy/licenses/c-mlib >>> >>> 2. >>> FILES_${PN}-dev = "${includedir}” >>> >>> I added that to .bb as you suggested so .so file doesn't end up in the >>> ${PN}-dev >>> Package — No longer see the error mentioned in previous mail. Thx >>> >>> 3. >>> This is what I suspected would happen - these files would normally >>> be part of >>> the ${PN}-dbg package, but since you've removed that from PACKAGES, they are >>> ending up unpackaged and that is not allowed. >>> >>> Did you mean the "install -m 0644 xxx yyy” to remove those files from the >>> PACKAGES? How do I copy .so and binaries from my target to the libdir or >>> bindir? >>> >>> After changing the .bb to remove the PACKAGES setting and FILES_${PN}-dev = >>> "${includedir}” >>> For the very first time, packages were built find, image were created under >>> image directory and c-mlib source is still in the yp workspace as shown >>> below: >>> >>> A.Packages were built >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find >>> tmp/deploy | grep c-mlib >>> tmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk >>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk >>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk >>> tmp/deploy/licenses/c-mlib >>> >>> B. Source files and the c-mlib git directory still have all the sources >>> (e.g just grep the mlib_api.c) >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find . >>> -name "mlib_api.c" >>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git/src/mlib_api.c >>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/packages-split/c-mlib-dbg/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c >>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/package/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ >>> >>> C. Image was built as well including binaries and libmlib.so >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$ >>> ls -ltr >>> total 1424 >>> -rw-r--r-- 1 dinhn dinhn 171701 Oct 5 01:17 datamodel_cache >>> -rw-r--r-- 1 dinhn dinhn 187434 Oct 5 01:17 invoke >>> -rw-r--r-- 1 dinhn dinhn 184961 Oct 5 01:17 invoke_b >>> -rw-r--r-- 1 dinhn dinhn 171701 Oct 5 01:17 protocol_infra >>> -rw-r--r-- 1 dinhn dinhn 191362 Oct 5 01:17 publisher >>> -rw-r--r-- 1 dinhn dinhn 187084 Oct 5 01:17 rpc-register >>> -rw-r--r-- 1 dinhn dinhn 179648 Oct 5 01:17 service >>> -rw-r--r-- 1 dinhn dinhn 174518 Oct 5 01:17 subscriber >>> >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$ >>> cd ../lib >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/lib$ >>> ls -ltr >>> total 856 >>> -rw-r--r-- 3 dinhn dinhn 872657 Oct 5 01:17 libmlib.so >>> >>> So it is all good for the first time, but thereafter that, if I do clean >>> “bitbake -c clean c-mlib” and “bitbake c-mlib” again. >>> All packages were build successful, but all data under c-mlib got was gone. >>> Nothing there including .c/h files, image directory etc... >>> >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$ >>> ls -ltr >>> total 0 >>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$ >>> >>> Please give me an idea why how to solve this? Sorry for a long email ;-)) >> >> Are the files present in the image/packages? Maybe it is just the >> bitbake cache skipping doing work it already did last time. >> >> -- >> Len Sorensen > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
