[OE-core] [PATCH 1/1] gcc-shared-source: Fix devtool missing patch/unpack tasks

[Richard Purdie]

On Sun, 2019-01-27 at 00:26 +0100, Tomasz Dziendzielski wrote:
> Devtool needs to execute these tasks so we cannot disable them
> but if SRC_URI is empty we don't need to disable them anymore.
> 
> Setting EXTERNALSRC so devshell can find the shared gcc sources.
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13036
> 
> Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski at gmail.com>
> ---
>  meta/recipes-devtools/gcc/gcc-shared-source.inc | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-shared-source.inc
> b/meta/recipes-devtools/gcc/gcc-shared-source.inc
> index aac4b49313..bc49e95a3a 100644
> --- a/meta/recipes-devtools/gcc/gcc-shared-source.inc
> +++ b/meta/recipes-devtools/gcc/gcc-shared-source.inc
> @@ -1,11 +1,6 @@
> -do_fetch() {
> -   :
> -}
> -do_fetch[noexec] = "1"
> -deltask do_unpack
> -deltask do_patch
> -
>  SRC_URI = ""
> 
>  do_configure[depends] += "gcc-source-${PV}:do_preconfigure"
>  do_populate_lic[depends] += "gcc-source-${PV}:do_unpack"
> +
> +EXTERNALSRC_pn-${PN} = "${S}"

You emailed me offlist and asked why we did this. I tried to explain
why and that we really do want to delete those tasks.

Let me try again.

gcc shared source is valuable because its large and we really don't
want to create many different copies of it (there are a ton of gcc
derived recipes which share this).

The presence of a task means it has a task checksum. Getting the
checksums of these tasks to match is hard as it has to match between
native, cross, crosssdk, target and multilib variants.

We used to do something similar to the above where we had the tasks and
just tried to make them "always match". It was basically a nightmare
and we switched to the standalone source recipe model.

Back in time, the simplest way to make this work and be very sure
nothing would break it was for the tasks simply not to exist. If I
remember rightly there are patches from a few years ago dealing with
horrible races around the patch tasks where they'd still try and
"unapply" patches from ${S} at the start of the patch task since there
were no patches in SRC_URI. We would have removed the fetch task as
well however there are(were?) assumptions about that existing which we
couldn't avoid. I suspect that could be deleted as well now.

If you want devtool to work with the gcc recipes, we'll need to teach
it to handle this kind of case. We are not hacking it by doing this and
adding a misleading/incorrect EXTERNALSRC entry. Breaking the gcc
recipes to fix devtool is not the way to resolve this. The above *will*
break gcc in subtle ways such as "random" patch removal in rebuilds )or
cleaning out ${S} at the start of do_unpack.

Cheers,

Richard