archiver.bbclass: Just archive gcc-source for all gcc recipes
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 archiver.bbclass: Just archive gcc-source for all gcc recipes
From: Mariano Lopez <[email protected]>
It is pointless to archive several times the gcc source. This change will archive gcc source once, for the gcc-source-{PV} recipe.
[YOCTO #9327]
--- meta/classes/archiver.bbclass | 6 ++++++ 1 file changed, 6 insertions(+)
meta/classes/archiver.bbclass +6 -0
@@ -61,6 +61,12 @@ python () { else: bb.debug(1, 'archiver: %s is included: %s' % (pn, reason)) + # We just archive gcc-source for all the gcc related recipes + if d.getVar('BPN', True) in ['gcc', 'libgcc'] \ + and not pn.startswith('gcc-source'): + bb.debug(1, 'archiver: %s is excluded, covered by gcc-source' % pn) + return + ar_src = d.getVarFlag('ARCHIVER_MODE', 'src', True) ar_dumpdata = d.getVarFlag('ARCHIVER_MODE', 'dumpdata', True) ar_recipe = d.getVarFlag('ARCHIVER_MODE', 'recipe', True)
Signature · 1 line
2.6.2
Quoted 18 lines · On Thu, Mar 24, 2016 at 8:26 AM <[email protected]> wrote:
From: Mariano Lopez <[email protected]>
It is pointless to archive several times the gcc source. This change will archive gcc source once, for the gcc-source-{PV} recipe.
[YOCTO #9327]
Signed-off-by Mariano Lopez <[email protected]>--- meta/classes/archiver.bbclass | 6 ++++++ 1 file changed, 6 insertions(+)meta/classes/archiver.bbclass +0
-0
meta/classes/archiver.bbclass python () { · line 70
Quoted 10 lines
meta/classes/archiver.bbclass +5
-0@@ -61,6 +61,12 @@ python () { else: bb.debug(1, 'archiver: %s is included: %s' % (pn, reason)) + # We just archive gcc-source for all the gcc related recipes + if d.getVar('BPN', True) in ['gcc', 'libgcc'] \ + and not pn.startswith('gcc-source'): + bb.debug(1, 'archiver: %s is excluded, covered by gcc-source' % pn) + return
Hmm, I wonder if it'd be possible to make this more generic, check for work-shared or something.
Quoted 14 lines · Christopher Larson
On Thu, Mar 24, 2016 at 8:26 AM <[email protected] <mailto:[email protected]>> wrote:
From: Mariano Lopez <[email protected] <mailto:[email protected]>>
+ # We just archive gcc-source for all the gcc related recipes
+ ifd.getVar('BPN', True)in ['gcc', 'libgcc'] \
+ and notpn.startswith('gcc-source'):
+ bb.debug(1, 'archiver: %s is excluded, covered by
gcc-source' % pn)
+ return
Quoted 1 line
Hmm, I wonder if it'd be possible to make this more generic, check for work-shared or something.
I was thinking the same when writing the patch, but it seems gcc is more of a corner case. The only two recipes that use work-shared are gcc and the kernel, the kernel case it's already covered checking for the class "kernel-yocto". In case of gcc we can't check for a class, we would need for work-shared and gcc, and that would be the almost the same comparison as is in the patch.
Mariano
Fair enough, thanks for the clarification!
Quoted 31 lines · Mariano Lopez
On 03/24/2016 12:04 PM, Christopher Larson wrote:
On Thu, Mar 24, 2016 at 8:26 AM <[email protected]> wrote:
From: Mariano Lopez <[email protected]>
Quoted 7 lines
meta/classes/archiver.bbclass +4
-0+ # We just archive gcc-source for all the gcc related recipes + if d.getVar('BPN', True) in ['gcc', 'libgcc'] \ + and not pn.startswith('gcc-source'): + bb.debug(1, 'archiver: %s is excluded, covered by gcc-source' %pn)
+ returnHmm, I wonder if it'd be possible to make this more generic, check for work-shared or something.
I was thinking the same when writing the patch, but it seems gcc is more of a corner case. The only two recipes that use work-shared are gcc and the kernel, the kernel case it's already covered checking for the class "kernel-yocto". In case of gcc we can't check for a class, we would need for work-shared and gcc, and that would be the almost the same comparison as is in the patch.
Mariano
Quoted 1 line · Christopher Larson
Fair enough, thanks for the clarification!
Its worth noting we did kill the concept of "shared stamps" from bitbake since it turned out to be a huge pain which could be solved in other ways which whilst ugly, are more reliable and work better. It was only ever used by gcc and didn't work with the kernel as the semantics were different.
I'd love a clean solution but have yet to see something that can work better than what we have today without invasive changes to bitbake.
Cheers,
Richard