From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: YP docs mailing list <docs@lists.yoctoproject.org>
Subject: Re: [docs] question about EXPORT_FUNCTIONS from bitbake user manual
Date: Tue, 16 Jan 2024 07:50:46 -0500 (EST) [thread overview]
Message-ID: <69a31dcd-19f-4fe-8c4b-823ca0c76047@crashcourse.ca> (raw)
In-Reply-To: <1ac7131af5e1f57c2348455fc2a52847d41b2683.camel@linuxfoundation.org>
On Tue, 16 Jan 2024, Richard Purdie wrote:
> On Tue, 2024-01-16 at 07:11 -0500, Robert P. J. Day wrote:
> > hoping that bitbake doc questions have been subsumed under the YP
> > docs mailing list ...
> >
> > i'm reading the section, "Flexible Inheritance for Class Functions",
> > here:
> >
> > https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html?highlight=inheritance#flexible-inheritance-for-class-functions
> >
> > and i understand the point of examples like autotools.bbclass defining
> > task functions like "autotools_do_install" so recipes that "inherit
> > autotools" can define their own "do_install" function that, somewhere
> > internally, calls "autotools_do_install".
> >
> > but what if the recipe that inherits autotools does *not* define its
> > own do_install() function? would it still pick up the
> > autotools_do_install? what if that recipe tried to:
> >
> > do_install:append = ...
> >
> > would that even make sense? which install function would it be
> > appending to?
> >
> > in short, while that section explains how to invoke the "base" task
> > function, it is not clear what happens if you don't invoke it that
> > way, and just try to take advantage of the "default" do_install.
>
> If you have:
>
> autotools_do_compile () {
> :
> }
>
> EXPORT_FUNCTIONS do_compile
>
> then do_compile will be magically mapped to autotools_do_compile, if
> there is no do_compile function defined by anything.
>
> If you have another similar class (lets say cmake) and have
>
> inherit autotools cmake
>
> then the last one is defined to "win" and do_compile would make to
> cmake_do_compile.
>
> This allows for functions that could do this as well:
>
> do_compile () {
> autotools_do_compile
> cmake_do_compile
> }
>
> Cheers,
>
> Richard
ah, that clears things up, thanks. maybe i'll submit a patch to add
that to the doc.
rday
prev parent reply other threads:[~2024-01-16 12:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 12:11 question about EXPORT_FUNCTIONS from bitbake user manual Robert P. J. Day
2024-01-16 12:39 ` [docs] " Richard Purdie
2024-01-16 12:50 ` Robert P. J. Day [this message]
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=69a31dcd-19f-4fe-8c4b-823ca0c76047@crashcourse.ca \
--to=rpjday@crashcourse.ca \
--cc=docs@lists.yoctoproject.org \
--cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).