[PATCH] utility-task: Add do_patchall task

[PATCH] utility-task: Add do_patchall task

[Matthew McClintock]

This is useful in a few scenarios:

1) A developer wants to be able to grep all the code in a particular
without having to run patch on various components until they guess the
right one (e.g. which component is generating an error/warning?)

2) Other code scanning tools that can be run without requiring a full
image to be built (legal, static code analysis, etc)

Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
---
 meta/classes/utility-tasks.bbclass | 7 +++++++
 meta/conf/documentation.conf       | 1 +
 2 files changed, 8 insertions(+)

diff --git a/meta/classes/utility-tasks.bbclass b/meta/classes/utility-tasks.bbclass
index da69c3a..b922685 100644
--- a/meta/classes/utility-tasks.bbclass
+++ b/meta/classes/utility-tasks.bbclass
@@ -64,3 +64,10 @@ do_fetchall[recideptask] = "do_${BB_DEFAULT_TASK}"
 do_fetchall() {
 	:
 }
+
+addtask patchall after do_patch
+do_patchall[recrdeptask] = "do_patchall do_patch"
+do_patchall[recideptask] = "do_${BB_DEFAULT_TASK}"
+do_patchall() {
+	:
+}
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 06527cb..5f4593c 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -40,6 +40,7 @@ do_package_write_rpm[doc] = "Creates the actual RPM packages and places them in
 do_package_write_tar[doc] = "Creates tar archives for packages and places them in the Package Feed area"
 do_packagedata[doc] = "Creates package metadata used by the build system to generate the final packages"
 do_patch[doc] = "Locates patch files and applies them to the source code"
+do_patchall[doc] = "Fetches, unpacks, and patches the source for all the components in a particular target"
 do_populate_lic[doc] = "Writes license information for the recipe that is collected later when the image is constructed"
 do_populate_sdk[doc] = "Creates the file and directory structure for an installable SDK"
 do_populate_sysroot[doc] = "Copies a subset of files installed by do_install into the sysroot in order to make them available to other recipes"
-- 
2.7.4

Re: [PATCH] utility-task: Add do_patchall task

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On 7 March 2017 at 20:19, Leonardo Sandoval <
leonardo.sandoval.gonzalez@linux.intel.com> wrote:

> >  meta/classes/utility-tasks.bbclass | 7 +++++++
> >  meta/conf/documentation.conf       | 1 +
>
> Doc patches goes into the yocto mailing list.


But this patches meta/conf/documentation.conf, which is part of oe-core.

Ross

[-- Attachment #2: Type: text/html, Size: 752 bytes --]

Re: [PATCH] utility-task: Add do_patchall task

[Leonardo Sandoval]

On Tue, 2017-03-07 at 13:48 -0600, Matthew McClintock wrote:
> This is useful in a few scenarios:
> 
> 1) A developer wants to be able to grep all the code in a particular
> without having to run patch on various components until they guess the
> right one (e.g. which component is generating an error/warning?)
> 
> 2) Other code scanning tools that can be run without requiring a full
> image to be built (legal, static code analysis, etc)
> 
> Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
> ---
>  meta/classes/utility-tasks.bbclass | 7 +++++++
>  meta/conf/documentation.conf       | 1 +

Doc patches goes into the yocto mailing list.


> 

Re: [PATCH] utility-task: Add do_patchall task

[Richard Purdie]

On Tue, 2017-03-07 at 13:48 -0600, Matthew McClintock wrote:
> This is useful in a few scenarios:
> 
> 1) A developer wants to be able to grep all the code in a particular
> without having to run patch on various components until they guess
> the
> right one (e.g. which component is generating an error/warning?)
> 
> 2) Other code scanning tools that can be run without requiring a full
> image to be built (legal, static code analysis, etc)
> 
> Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
> ---
>  meta/classes/utility-tasks.bbclass | 7 +++++++
>  meta/conf/documentation.conf       | 1 +
>  2 files changed, 8 insertions(+)

I have mixed feelings on this. Whilst I can see the attraction, extra
tasks like this do actually have a parsing overhead. We already have a
lot of them and its only a question of time before someone wants
another XXXall task adding.

I'm wondering if we can solve this at the bitbake level instead with a
new parameter instead? That would allow us to delete tasks and speed up
parsing rather than slow things down.

Cheers,

Richard

Re: [PATCH] utility-task: Add do_patchall task

[Matthew McClintock]

On Tue, Mar 7, 2017 at 2:47 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2017-03-07 at 13:48 -0600, Matthew McClintock wrote:
>> This is useful in a few scenarios:
>>
>> 1) A developer wants to be able to grep all the code in a particular
>> without having to run patch on various components until they guess
>> the
>> right one (e.g. which component is generating an error/warning?)
>>
>> 2) Other code scanning tools that can be run without requiring a full
>> image to be built (legal, static code analysis, etc)
>>
>> Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
>> ---
>>  meta/classes/utility-tasks.bbclass | 7 +++++++
>>  meta/conf/documentation.conf       | 1 +
>>  2 files changed, 8 insertions(+)
>
> I have mixed feelings on this. Whilst I can see the attraction, extra
> tasks like this do actually have a parsing overhead. We already have a
> lot of them and its only a question of time before someone wants
> another XXXall task adding.
>
> I'm wondering if we can solve this at the bitbake level instead with a
> new parameter instead? That would allow us to delete tasks and speed up
> parsing rather than slow things down.

Can you drop a few hints as to where to look to add this to bitbake? I
can look at it a bit further.

One other thing we were thinking about was doing for only things that
will run on or be on the target (e.g. skipping the toolchain side).

-M

Re: [PATCH] utility-task: Add do_patchall task

[Paul Eggleton]

On Wednesday, 8 March 2017 9:47:23 AM NZDT Richard Purdie wrote:
> On Tue, 2017-03-07 at 13:48 -0600, Matthew McClintock wrote:
> > This is useful in a few scenarios:
> > 
> > 1) A developer wants to be able to grep all the code in a particular
> > without having to run patch on various components until they guess
> > the
> > right one (e.g. which component is generating an error/warning?)
> > 
> > 2) Other code scanning tools that can be run without requiring a full
> > image to be built (legal, static code analysis, etc)
> > 
> > Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
> > ---
> >  meta/classes/utility-tasks.bbclass | 7 +++++++
> >  meta/conf/documentation.conf       | 1 +
> >  2 files changed, 8 insertions(+)
> 
> I have mixed feelings on this. Whilst I can see the attraction, extra
> tasks like this do actually have a parsing overhead. We already have a
> lot of them and its only a question of time before someone wants
> another XXXall task adding.
> 
> I'm wondering if we can solve this at the bitbake level instead with a
> new parameter instead? That would allow us to delete tasks and speed up
> parsing rather than slow things down.

FYI there is a bug open for this (currently assigned to me, but it's in the 
"new" state so anyone's welcome to take it):

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=7733

I suspect most of this would need to be handled in lib/bb/runqueue.py; 
actually adding the option would be in main.py.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] utility-task: Add do_patchall task

[Matthew McClintock]

Posted an alternate patch to bitbake mailing list.

-M

On Tue, Mar 7, 2017 at 4:33 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday, 8 March 2017 9:47:23 AM NZDT Richard Purdie wrote:
>> On Tue, 2017-03-07 at 13:48 -0600, Matthew McClintock wrote:
>> > This is useful in a few scenarios:
>> >
>> > 1) A developer wants to be able to grep all the code in a particular
>> > without having to run patch on various components until they guess
>> > the
>> > right one (e.g. which component is generating an error/warning?)
>> >
>> > 2) Other code scanning tools that can be run without requiring a full
>> > image to be built (legal, static code analysis, etc)
>> >
>> > Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
>> > ---
>> >  meta/classes/utility-tasks.bbclass | 7 +++++++
>> >  meta/conf/documentation.conf       | 1 +
>> >  2 files changed, 8 insertions(+)
>>
>> I have mixed feelings on this. Whilst I can see the attraction, extra
>> tasks like this do actually have a parsing overhead. We already have a
>> lot of them and its only a question of time before someone wants
>> another XXXall task adding.
>>
>> I'm wondering if we can solve this at the bitbake level instead with a
>> new parameter instead? That would allow us to delete tasks and speed up
>> parsing rather than slow things down.
>
> FYI there is a bug open for this (currently assigned to me, but it's in the
> "new" state so anyone's welcome to take it):
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=7733
>
> I suspect most of this would need to be handled in lib/bb/runqueue.py;
> actually adding the option would be in main.py.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre