Re: [OE-core] trying to summarize the flexibility in bbappend'ing to kernel recipes
Quoting "Robert P. J. Day" :
(i'm going to reply to this post just to keep everything in the
same thread.)
... big snip ...
in addition to all of that possible bbappend customization in my earlier
note, i just noticed i forgot to mention this possibility of conditional
prepending to FILESEXTRAPATHS, which is (was?) actually used for the
poky override for the psplash recipe:
FILESEXTRAPATHS_prepend_poky := "${THISDIR}/files:"
of course, in this case, the same effect would come from having a
"files/poky/" subdirectory. just trying to be complete.
ok, back to work ...
rday
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] trying to summarize the flexibility in bbappend'ing to kernel recipes
(i'm going to reply to this post just to keep everything in the
same thread.)
i'm going to try to clarify all of the ways one can bbappend to a kernel
recipe, and i'll have a few questions along the way. as before, let's
assume i have access to a layer that already gives me two base recipes,
say:
* linux_4.0.bb
* linux_4.1.bb
which already come with their own base patches and .cfg and .scc files,
and i want to extend that for two moderately-related target boards,
"mach1" and "mach2", for which i will supply the machine definition
files. i want to be able to handle all possible combinations of kernel
version and target board in a single layer, of course, and while i'll
keep things simple with two kernel versions and two target boards,
this should trivially extend to more of each.
bbappend files
-
first, i could start with kernel version-specific .bbappend files:
* linux_4.0.bbappend
* linux_4.1.bbappend
this is *probably* what i'll do, although there are a couple other
possibilities. if the customization is similar, i could just use a
single wildcard bbappend file to handle both with something like:
* linux_4.%.bbappend, or
* linux_%.bbappend
i could also (based on that revelation from chris larson that *all* matching
bbappend files will be applied), have a combination of version-specific
*and* wildcard bbappend files, but i suspect that way lies madness and
wow, much overkill. so i think i'll go with one bbappend file per kernel
version.
FILESEXTRAPATHS
---
as i mentioned, i once wrote up what i think is still a correct
explanation of FILESEXTRAPATHS here:
http://www.crashcourse.ca/wiki/index.php/Poky_bbappend_FILESEXTRAPATHS
and i can see a couple possibilities for setting this.
first, if i want entirely separate patch/scc/cfg directories for each
kernel version, each bbappend file would include the line:
FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:"
and i would then create individual customization directories for each
kernel version:
* linux-4.0/
* linux-4.1/
(i'm assuming that if i did indeed use a wildcard .bbappend file, the
value of ${BP} would be set properly based on my PREFERRED_VERSION of
the kernel, yes? i can't imagine how that couldn't be true, but let's
just make sure of that.)
the next possibility for FILESEXTRAPATHS would be if all of my local
customization applied (almost) equally to all possible targets,
i guess i could use the same line in all my bbappend files -- a line
of one of the following forms:
* FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
* FILESEXTRAPATHS_prepend := "${THISDIR}/linux:"
* FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
* FILESEXTRAPATHS_prepend := "${THISDIR}/rday:"
or whatever i wanted to call it, and just create the corresponding
single customization directory to be used by *all* of the bbappend files.
the final possibility would seem to be if i want some
kernel version-specific customization *and* some generic customization,
i could create both types of directories:
* linux-4.0/ (for only 4.0)
* linux-4.1/ (for only 4.1)
* linux/ (for all versions)
and each bbappend file would use the line:
FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}:"
so that kernel-specific customization would be searched for first, then
generic customization. that's probably more complicated than i need,
i just want to know that it's *possible*, yes?
Conditional SRC_URI
--- ---
Given that some customization will differ from target board to target
board, I know I can add conditional customization to my bbappend files
with the syntax:
SRC_URI_mach1 += "..."
SRC_URI_mach2 += "..."
but if it's just machine-dependent, I know there's another way to do this,
coming shortly. that is, if i'm going to override based on only values
in FILESOVERRIDES and not OVERRIDES in general, i prefer the
subdirectory approach.
[side note: i asked about this once upon a time -- is there a
preferred style for this in the sense of which of these two forms
is the encouraged form in bbappend files?
SRC_URI_mach1 += "..."
SRC_URI_append_mach1 = "..."
just curious. anyway, onward ...]
FILESOVERIDES and FILESEXTRAPATHS subdirectories
- --- --- --
again, referring to what i *hope* is a correct explanation i wrote for
FILESEXTRAPATHS here (and please let me know if i screwed that up):
http://www.crashcourse.ca/wiki/index.php/Poky_bbappend_FILESEXTRAPATHS
for each directory "d/" prepended to FILESEXTRAPATHS, the search order for
a new SRC_URI item will be:
* d/${DISTROOVERRIDES}
* d/${MACHINEOVERRIDES}
* d/${TRANSLATED_TARGET_ARCH}
* d/
so in my example on my wiki page above, building a "poky" distro for
a beaglebone with my customization directory being named "files/",
th
Re: [OE-core] trying to summarize the flexibility in bbappend'ing to kernel recipes
A bbappend basically concatenates to the recipe in bitgbake, so it can do anything the recipe can do, within reason, so yes, use of filespath and overrides works the way it's always worked with recipes. On Wed, Feb 24, 2016 at 3:00 PM Robert P. J. Day wrote: >let's see if i can explain this properly -- i want to enumerate all > possible ways to .bbappend to a kernel recipe if i have multiple > target machines and multiple kernel recipes. so let's imagine the > following scenario -- i grab a layer that has two recipe files for > two versions of the kernel, *and* i have two target boards. so ... > > * linux-4.0.bb > * linux-4.1.bb > > and i have two target machines, "mach1" and "mach2", and the combination > of all of these involves various patches. so what are my possibilities? > >first (as long as i understood chris larson properly), i can define > two separate .bbappend files: > > * linux-4.0.bbappend > * linux-4.1.bbappend > > or i can define a single wildcard .bbappend file that covers both: > > * linux-4.%.bbappend > > so far, so good. > >next, in these .bbappend files, SRC_URI can refer to any of: > > * .scc files > * .patch/.diff files > * .cfg files > > so each of my two .bbappend files can enumerate a different set > of files to be applied to that version of the kernel. but wait ... > there's more. > >in each .bbappend file, i can conditionally include files in the > SRC_URI, as in: > > * SRC_URI_mach1 += mach1.patch > > so depending on the target machine, i can conditionally include > any of patch files, cfg files or scc files. > >in addition, i can take advantage of FILESEXTRAPATHS, that i once > wrote up here: > >http://www.crashcourse.ca/wiki/index.php/Poky_bbappend_FILESEXTRAPATHS > > so that i have a ridiculous set of possibilities as to which patch > files will be applied depending on the: > > * architecture > * distro > * target machine > > am i making sense so far? because there will be more coming shortly. > > rday > > > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] trying to summarize the flexibility in bbappend'ing to kernel recipes
let's see if i can explain this properly -- i want to enumerate all possible ways to .bbappend to a kernel recipe if i have multiple target machines and multiple kernel recipes. so let's imagine the following scenario -- i grab a layer that has two recipe files for two versions of the kernel, *and* i have two target boards. so ... * linux-4.0.bb * linux-4.1.bb and i have two target machines, "mach1" and "mach2", and the combination of all of these involves various patches. so what are my possibilities? first (as long as i understood chris larson properly), i can define two separate .bbappend files: * linux-4.0.bbappend * linux-4.1.bbappend or i can define a single wildcard .bbappend file that covers both: * linux-4.%.bbappend so far, so good. next, in these .bbappend files, SRC_URI can refer to any of: * .scc files * .patch/.diff files * .cfg files so each of my two .bbappend files can enumerate a different set of files to be applied to that version of the kernel. but wait ... there's more. in each .bbappend file, i can conditionally include files in the SRC_URI, as in: * SRC_URI_mach1 += mach1.patch so depending on the target machine, i can conditionally include any of patch files, cfg files or scc files. in addition, i can take advantage of FILESEXTRAPATHS, that i once wrote up here: http://www.crashcourse.ca/wiki/index.php/Poky_bbappend_FILESEXTRAPATHS so that i have a ridiculous set of possibilities as to which patch files will be applied depending on the: * architecture * distro * target machine am i making sense so far? because there will be more coming shortly. rday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
