All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: openembeded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: the awkwardness of using core-image.bbclass
Date: Sat, 12 Jul 2014 05:53:38 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1407120541230.5275@localhost> (raw)
In-Reply-To: <CAMKF1speMwTzKbLKm8hBXQ14ZgqmHSTKNUt-qS1sw14ac9iw4w@mail.gmail.com>

On Fri, 11 Jul 2014, Khem Raj wrote:

> >   i know, which is exactly what is so counter-intuitive with the way
> > the above is done. you can override those two variables, but not
> > CORE_IMAGE_BASE_INSTALL directly, it just seems silly.
>
> why do you want CORE_IMAGE_BASE_INSTALL to be overridable ? unless
> you want to construct image of your own completely from scratch but
> then why would you want to inherit properties from core-image class.

  one last post on this, then i'll move on -- i didn't want this to
become so involved.

  quite simply, even if you inherit from core-image, the setting of
CORE_IMAGE_BASE_INSTALL *is* overridable -- it's simply overridable in
a disgusting, grotesque, non-intuitive and incomprehensible way.

  i'm happy to leave core-image.bbclass the way it is, and i'll admit
that it works just fine as long as you recognize the crippled way it's
implemented. any base class that requires horrid code like this in an
inheriting class:

IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"
inherit core-image

to allegedly *inherit* from core-image but still mangle the allegedly
really, really important value of CORE_IMAGE_BASE_INSTALL is just ...
wrong.

  so, i'm happy to leave things the way they are, knowing that in my
future OE/yocto courses, i will continue to introduce the section on
core images with the lead-in, "you're not going to *believe* what they
did here", after which students will, as always, be wiping their eyes
from laughter.

  and as forrest gump once said, "and that's all i have to say about
that."  carry on.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


  reply	other threads:[~2014-07-12  9:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11 16:51 the awkwardness of using core-image.bbclass Robert P. J. Day
2014-07-11 17:56 ` Rudolf Streif
2014-07-11 22:30   ` Robert P. J. Day
2014-07-12  5:06     ` Khem Raj
2014-07-12  9:53       ` Robert P. J. Day [this message]
2014-07-14  9:34 ` Paul Eggleton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.11.1407120541230.5275@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.