It'd be a great usability enhancement to implement a suite of shell commands to help CLI users interoperate with the system which are 'enabled' when the oe-init-build-env script is sourced. Some examples to get us started: oecd PN - change into the directory containing metadata for the package PN. oeed PN <FILE> - open the recipe file for PN with $EDITOR, if the optional FILE is passed open file FILE within the tree of PN. oels PN <SUBDIR> - list the contents of the metadata directory for PN. Example usage: joshual@shamshir:~/Projects/Yocto/poky $ oels connman connman-0.75 connman-gnome_0.5.bb connman_0.75.bb connman-gnome connman.inc joshual@shamshir:~/Projects/Yocto/poky $ oels connman connman-0.75 add_xuser_dbus_permission.patch dbusperms.patch connman xtables_version.patch joshual@shamshir:~/Projects/Yocto/poky $ oecd connman $ ls connman-0.75 connman-gnome_0.5.bb connman_0.75.bb connman-gnome connman.inc connman_git.bb joshual@shamshir:~/Projects/Yocto/poky $ oecd connman connman-gnome $ ls 3g.patch security-type.patch $ pwd /home/joshual/Projects/Yocto/poky/meta/recipes-connectivity/connman/connman-gnome joshual@shamshir:~/Projects/Yocto/poky $ oeed connman There are two bb recipes in /home/joshual/Projects/Yocto/poky/meta/recipes-connectivity/connman, please select an option and press return to continue, return with no selection will pick the default (*): 1) connman_0.75.bb (*) 2) connman-gnome_0.5.bb 3) connman.inc <<Return loads /home/joshual/Projects/Yocto/poky/meta/recipes-connectivity/connman/connman_0.75.bb with $EDITOR>> joshual@shamshir:~/Projects/Yocto/poky $ oeed connman xtables_version.patch <<Loads /home/joshual/Projects/Yocto/poky/meta/recipes-connectivity/connman/connman-0.75/xtables_version.patch with $EDITOR>> It will be necessary to have the commands be aware of bblayers.conf entries and the layers' priorities. I envisage that under the hood these commands would just be running find over the enabled layers with some simple heuristics (search higher priority layers first, etc).
We wanted to document our own developer workflows for different types of developers, that could be great source of commands which should be simplified by these helpers.
Martin: I'd love to see any workflow documentation like that you might have...
devtool accomplishes at least part of where I think this was aimed, FWIW.
devtool is able to accomplish the tricky parts of what this bug requests and is a more complete solution to simplifying working with OE metadata, in light of devtool these helpers don't make much sense.