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
