[poky] Patch.bbclass URL Reasoning

[Bruce Ashfield]

On Tue, Mar 27, 2012 at 9:05 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> On Tuesday 27 March 2012 14:58:23 Robert Abel wrote:
>> On 27.03.2012 14:55, Paul Eggleton wrote:
>> > However if I needed to do what you want to do I would do it differently -
>> > instead of modifying the patches, why not just modify the file(s) in the
>> > source code directly? I would suggest using sed in a
>> > do_configure_prepend() to change the values in the source to the desired
>> > value from a variable. Depending on the complexity you could have the
>> > patches change the values to some easily replaceable string beforehand.
>>
>> That's exactly what I'm doing right now. However, since I'm patching the
>> kernel and users could theoretically add patches containing my magic
>> strings, I wanted to avoid a sed on git\* and instead only edit *.patch
>> in ${WORKDIR}, which is why I'm asking why the copied patches go unused.
>
> Well, I can't answer that, but I don't think it's too difficult to come up with
> a string that's unlikely to ever occur in the kernel sources.

Or perhaps come up with a different model all together that avoids the need
to modify the patches on the fly :) I've had to do things very similar to this
before, and I've solved it with the include of a generated file.

That being said, I am painfully aware of the different patch locations and what
does or doesn't get used, since I had to adapt the feature processing of
linux yocto to figure out the WORKDIR variant (so there would be somewhere
writable).

That being said, the current behaviour has advantages that via the
absolute / source location of the patch, it's possible to examine the entire
directory without having to modify bitbake to recognize the files and do the
copy to WORKDIR.  Summary: the current behaviour works, and if it changed,
existing semantics would break, so if it was changed the return of WORKDIR
versus source location would be better done as an option.

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"