Feature request: Simplify the layer.conf file so that ALL recipes are available.

[madscientist42]

In order to properly use your metadata as it is, I'd have to fork your repo to be able to drop in the other pieces of the metadata layer (Per your instructions in the readme, if I want things like the SSH and CLU functionality in my recipe...) - this is at the least annoying.

VERY un-Yocto-like there. It should be a pick list wherein I add it to the image buildout and you shouldn't care about that and do what you're doing. It means I have lurking mods in a git repository pull of your stuff that most probably don't want there- and that I have to modify things in the config just to get recipes to build.

Suggest a simpler construct there than what you have in there right now. From one of my metadata layers (meta-runit...):

`
BBFILES += "
${LAYERDIR}/recipes-//.bb
${LAYERDIR}/recipes-//.bbappend
${LAYERDIR}//recipes-//.bb
${LAYERDIR}//recipes-//.bbappend
"

BBFILES += "${@' '.join('${LAYERDIR}/external/%s/recipes*//.bb' % layer
for layer in BBFILE_COLLECTIONS.split() if os.path.exists(os.path.join('${LAYERDIR}','external',layer)))}"
BBFILES += "${@' '.join('${LAYERDIR}/external/%s/recipes*//.bbappend' % layer
for layer in BBFILE_COLLECTIONS.split() if os.path.exists(os.path.join('${LAYERDIR}','external',layer)))}"

`

In this example, it catches all the content and leaves it up to the dev leveraging the layer to specify out the needed things in the layer, with RDEPENDS in the recipes themselves as needed- providing an "external" annex for .bbappends for things not in the core layer that lets the runit supervisor and init engine to be a first-class citizen in Yocto systems in the manner that Systemd support is.

[dgarske]

@night1rider any thoughts on this feedback from @madscientist42 ?

[night1rider]

Hello @madscientist42, thanks for the feedback on our yocto layer.

This seems to stem from the README not properly reflecting on how you can use the layer. This is because of it being not properly updated after #75.

The layer.conf in meta-wolfssl is currently setup in a way so that when you want to build wolfCLU or wolfSSH it will properly pull in the correct configuration options needed with wolfSSL to build those libraries. We currently use IMAGE_INSTALL to gate this correctly so that yocto knows if you want to build wolfCLU it will pull in the correct .bbappend's which applies the needed configuration options to wolfSSL so that wolfCLU can be compiled since it relies on certain options being set in the wolfSSL library. This also ensures that wolfSSL doesn't contain configuration options that are not intended by the builder.

I've opened up PR #86 to hopefully address your concern, with needing to fork to meta-wolfssl, with some updates to the README and a cleanup of some the commented out lines in layer.conf.

If not could you provide a little more explanation on what you are trying to do that that our layer inhibits/blocks functionality of that requires a fork?

[G-E-N-E]

I've found that using IMAGE_INSTALL as the gate makes usage of the layer as-is impossible in layer environments in which you build multiple images where all images do not wish to include the desired wolfssl components.

Initially I thought the IMAGE_INSTALL within a bb file would suffice but I've found that the IMAGE_INSTALL inside of image .bb files is not parsed before the layer.conf of the meta-wolfssl layer and so the only place where the IMAGE_INSTALL actually has an influence is inside of my local.conf; however, if it's placed there it will impact ALL images, even if the wolfssl component is not wanted.

I suggest that instead of using IMAGE_INSTALL, you instead use a custom variable such as WOLFSSL_ENABLE_RECIPES or something. That way you can put that in the local.conf, layer.conf will load what is desired and images can use IMAGE_INSTALL for what it is intended to be used for. This would also allow things like bitbake wolfprovider without needing layers.conf it to be modified (avoiding modification of third-party layers is good).

EDIT: I think the conditional logic must actually be moved inside of the bb/bbappend files to support multiple images. If one image needs recipes you have to bring them in from the layer and once you do I don't know a way to avoid those recipes (thinking things like bbappend files for openssl or whatever) from impacting the images which may also have those recipes but that do not want the bbappend. If it's inside the bb/bbappend files I think IMAGE_INSTALL could work again but you'd not be able to do something like bitbake wolfprovider; not a terrible loss as that's usually something only needed during development and could be done with local modification of the layer.conf inside dev environments or temp inclusion of IMAGE_INSTALL in local.conf

EXTRA_OECONF += "--enable-wolfclu"
EXTRA_OECONF += "${@bb.utils.contains('IMAGE_INSTALL', 'wolfclu', '--enable-wolfclu', ''", d)}

[night1rider]

@G-E-N-E Thanks for your comment. I see the issue you are talking about and I am able to reproduce it.

Your suggestion of:
EXTRA_OECONF += "${@bb.utils.contains('IMAGE_INSTALL', 'wolfclu', '--enable-wolfclu', '', d)}"
does not work from my testing because it seems when the build system is looking at wolfssl.bb it also does not have access to IMAGE_INSTALL at that moment.

I will be working on a fix to enable it to be built based on the IMAGE_INSTALL set by the image recipe.

If you don't mind would you open up a new issue on the meta-wolfssl repo about this so its easier to track?