On Tue, May 29, 2018 at 12:40 PM, Mark Hatle <mark.ha...@windriver.com> wrote: > On 5/29/18 2:22 PM, Khem Raj wrote: >> On Mon, May 28, 2018 at 6:38 AM, Mark Asselstine >> <mark.asselst...@windriver.com> wrote: >>> This is a new class which can be used (for example via USER_CLASSES in >>> local.conf) to make your build more development friendly. When >>> included this class will create symlinks to the various bb and >>> bbappend files in WORKDIR. >>> >>> Normally when you are debugging or extending a package's recipe files >>> a developer will employ one of a few indirect techniques to determine >>> where bb and bbappends files associated with a recipe exist. For >>> example they might use bitbake-layers show-recipes or similar, or >>> simply rely on their experience to guide them. Even after working with >>> openembedded for serveral years now I find these techniques tedious >>> and time consuming, and sometimes even hit and miss. >>> >>> Since the whereabouts of these files are already stored in various >>> files at parse time we can create symlinks to simplify the task of >>> finding these files, making them available in WORKDIR for easy >>> inpsection and in a convenient location if using devshel for instance. >>> >>> For now this work is completely optional but we could conceivable make >>> this the default behavior if folks find it is convenient and the cost >>> of performing these operations across all builds is minimal enough. >>> >>> recipe_links can safely be added to USER_CLASSES for existing builds, >>> care has been taken to avoid this action causing anything to be >>> rebuilt. After this has been added you can either 'bitbake <recipe> -C >>> unpack' or 'bitbake <recipe> -c create_recipe_links' to cause the >>> links to be created in the WORKDIR for the specified recipe. >>> >> >> I think this is not complementing devtool workflow, even though its >> not going to hurt it. >> however, devtool workflow is what we should be targeting as primary >> workflow for OE >> and I do not see a benefit of this in that regard. > > I think the same could be said about other bbclasses that are not enabled. > devtool is not the only workflow, and a lot of people like to work directly > using 'bitbake -c devshell' or similar still. > > As an optional user class, I do think this is reasonable and helpful to many > folks. > > (it also does not clash with the devtool workflow at all, so even if enabled a > devtool user won't be negatively impacted by it.)
Dont get me wrong I do see that part. I was trying to make a case for promoting devtool workflow. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
