Wind River already has a mechanism to do something like this, called templates.
https://github.com/WindRiver-Labs/wr-template/tree/WRLINUX_10_21_BASE
Each template can have (optionally):
# README - template README file
# require - list of other templates required for this one
# template.conf - template configuration fragment
# image.inc - image fragment
# bsp-pkgs.conf - BSP specific configuration fragment
# bsp-pkgs.inc - BSP specific image fragment
# The 'bsp-pkgs' files can only be in a template in a layer that provides a
# specific conf/machine/${MACHINE}.conf file and layers it may contain,
# otherwise they will be ignored
I'm not saying what is implemented is a perfect solution, but it made a
'configuration fragment' approach to system configuration much easier when I
worked with it.
(For examples see:
https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_21_BASE/templates/feature)
You could do things (in your local.conf, or machine.conf or distro.conf) like:
WRTEMPLATE += "dpdk"
This would add the dpdk recipes to your image and also configure the kernel for
dpdk.
https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_21_BASE/templates/feature/dpdk
--Mark
On 9/1/22 10:29 AM, Alexander Kanavin wrote:
On Thu, 18 Aug 2022 at 11:27, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
The intent is the user could add something like:
require conf/yocto-autobuilder/x32.inc
or
require conf/yocto-autobuilder/multilib-mipsn32.inc
and similar to their local.conf and more easily replicate
configurations.
This could be a subset of a broader feature, one that allows adding
and removing pre-canned 'config fragments' to local.conf. The proposal
is to have such fragments live in
meta-somelayer/conf/fragments/path/to/some/fragment (I think allowing
multiple levels is beneficial here), and each fragment would start
with a comment explaining what it does followed by the actual
settings.
Then adding fragments can be done by appending them to local.conf, and
removing by looking for markers in local.conf and editing it out,
which probably could use a helper tool/subcommand.
Layers could also declare 'non-optional' fragments which get included
automatically by the fact of including the layer into the build, which
means layer.conf can go back to being short and sweet and to the
point.
Thoughts?
I would like to see if we can switch the eSDK to use the json format
btw. I suspect that may be one of your next steps? :)
I don't think I understand this, can you explain?
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170229):
https://lists.openembedded.org/g/openembedded-core/message/170229
Mute This Topic: https://lists.openembedded.org/mt/93407466/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
