[OE-core] [PATCH] kernel.bbclass: add lzop dependency

Bruce Ashfield bruce.ashfield at gmail.com
Thu Aug 4 01:39:59 UTC 2016


On Wed, Aug 3, 2016 at 8:53 AM, Trevor Woerner <twoerner at gmail.com> wrote:

> On Mon 2016-08-01 @ 03:08:36 PM, Burton, Ross wrote:
> > On 1 August 2016 at 15:07, Bruce Ashfield <bruce.ashfield at gmail.com>
> wrote:
> >
> > > Not a large dependency, but it does bring to mind the question if this
> > > could be conditional on the type of image being built ? via  distro
> > > feature, some other mechanism ?
> > >
> >
> > Exactly this: image building adds dependencies automatically based on
> what
> > is actually being used, so can the kernel do this too?
>
> The way the build knows which image was built is to build the kernel then
> look
> in the output directory to see what extension was given to the artifact.
> iow,
> it only discovers the dependency partway through the build; it doesn't know
> the dependency when the build starts.
>
> Either bitbake will have to put together the kernel's config at the start
> of
> the build, then parse through it to try to determine which kernel will be
> built, or we need some sort of mechanism that allows us to add dependencies
> partway through a build, or we can add (yet another) build variable and
> hope
> people are able to keep it in sync.
>
>
I'm on vacation for the next two weeks, so sorry for the slow reply.

Wouldn't something like PACKAGECONFIG work here ? Something automatic
is going to be complex (like you describe), but something like this would
be an
easy way for a BSP (or other) layer to bbappend the kernel and add this as
a dependency.

... but then again, I suppose they could currently just bbappend the kernel
recipe
and add it directly to the DEPENDS.

Bruce


>
> ...or we could just add lzop-native as a static dependency in the
> off-chance that
> it's needed.
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160803/44504327/attachment-0002.html>


More information about the Openembedded-core mailing list