<div dir="ltr">Keying off of PN when processing BBINCLUDED is going to cause problems for cross recipes whose pn is altered in the recipe but isn't included in the bbappend path. bbappends are based on the recipe basename, not PN.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 29, 2018 at 12:47 PM Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, May 29, 2018 at 12:40 PM, Mark Hatle <<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>> wrote:<br>
> On 5/29/18 2:22 PM, Khem Raj wrote:<br>
>> On Mon, May 28, 2018 at 6:38 AM, Mark Asselstine<br>
>> <<a href="mailto:mark.asselstine@windriver.com" target="_blank">mark.asselstine@windriver.com</a>> wrote:<br>
>>> This is a new class which can be used (for example via USER_CLASSES in<br>
>>> local.conf) to make your build more development friendly. When<br>
>>> included this class will create symlinks to the various bb and<br>
>>> bbappend files in WORKDIR.<br>
>>><br>
>>> Normally when you are debugging or extending a package's recipe files<br>
>>> a developer will employ one of a few indirect techniques to determine<br>
>>> where bb and bbappends files associated with a recipe exist. For<br>
>>> example they might use bitbake-layers show-recipes or similar, or<br>
>>> simply rely on their experience to guide them. Even after working with<br>
>>> openembedded for serveral years now I find these techniques tedious<br>
>>> and time consuming, and sometimes even hit and miss.<br>
>>><br>
>>> Since the whereabouts of these files are already stored in various<br>
>>> files at parse time we can create symlinks to simplify the task of<br>
>>> finding these files, making them available in WORKDIR for easy<br>
>>> inpsection and in a convenient location if using devshel for instance.<br>
>>><br>
>>> For now this work is completely optional but we could conceivable make<br>
>>> this the default behavior if folks find it is convenient and the cost<br>
>>> of performing these operations across all builds is minimal enough.<br>
>>><br>
>>> recipe_links can safely be added to USER_CLASSES for existing builds,<br>
>>> care has been taken to avoid this action causing anything to be<br>
>>> rebuilt. After this has been added you can either 'bitbake <recipe> -C<br>
>>> unpack' or 'bitbake <recipe> -c create_recipe_links' to cause the<br>
>>> links to be created in the WORKDIR for the specified recipe.<br>
>>><br>
>><br>
>> I think this is not complementing devtool workflow, even though its<br>
>> not going to hurt it.<br>
>> however, devtool workflow is what we should be targeting as primary<br>
>> workflow for OE<br>
>> and I do not see a benefit of this in that regard.<br>
><br>
> I think the same could be said about other bbclasses that are not enabled.<br>
> devtool is not the only workflow, and a lot of people like to work directly<br>
> using 'bitbake -c devshell' or similar still.<br>
><br>
> As an optional user class, I do think this is reasonable and helpful to many folks.<br>
><br>
> (it also does not clash with the devtool workflow at all, so even if enabled a<br>
> devtool user won't be negatively impacted by it.)<br>
<br>
Dont get me wrong I do see that part. I was trying to make a case for promoting<br>
devtool workflow.<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Christopher Larson<br>kergoth at gmail dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Senior Software Engineer, Mentor Graphics</div></div></div></div>