[OE-core] [PATCH] recipe_links.bbclass: introduction

[Khem Raj]

On Tue, May 29, 2018 at 12:40 PM, Mark Hatle <mark.hatle at 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.asselstine at 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.