Thanks Christopher! Yes, this is exactly what I needed. Much appreciation.
On Tue, Dec 29, 2015 at 12:40 PM, Christopher Larson <[email protected]> wrote: > > On Tue, Dec 29, 2015 at 1:30 PM, Logan Buchy <[email protected]> > wrote: > >> I've got a third-party SDK given to me by our SoC provider. The SDK >> contains >> * Vanilla Linux kernel with a set of patches that adds drivers for SoC >> peripherals >> * Proprietary bootloader >> * Proprietary binary libraries >> * Proprietary firmware for on-chip peripherals >> * A build system which compiles everything >> >> This SDK comes a a big tarball. Splitting the tarball into separate >> tarballs is not desirable since this would need to be done every time the >> provider issues an update (which comes as another big tarball). >> >> What I have now is a recipe that compiles and installs the entire SDK, >> which works alright but I am looking to split up the SDK into separate >> packages with associated do_configure/do_compile/do_install tasks. For >> example, I would like to split this into packages that provide: >> * virtual/kernel >> * proprietary-binary-blob >> * soc-kernel-drivers >> * proprietary-firmware-blob >> >> What I am wondering about is how would I go about writing multiple >> recipes that share the same tarball without having bitbake untar it for >> each recipe. Is this even possible? Are there any examples of packages >> that do this? >> >> My best guess about how to go about this would be to create a class which >> defines a do_fetch/do_unpack routine and then for each package, inherit the >> class and define custom do_configure/do_compile/do_install routines. >> > > See the gcc-source recipe and gcc-shared-source.inc. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
