[PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Richard Purdie]

gcc-cross cannot build without linux-libc-headers but doesn't explicitly depend on
it relying on the implied dependency through libc. With cases where pieces
can be installed through sstate, we now need this explicit dependency to
ensure builds with partial sstate work.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
index 6d160d6..cde08ee 100644
--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -1,6 +1,6 @@
 inherit cross
 
-DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
+DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"
 PROVIDES = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++"
 
 require gcc-configure-cross.inc

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Phil Blundell]

On Thu, 2012-11-22 at 21:36 +0000, Richard Purdie wrote:
> -DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
> +DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"

gcc-cross isn't particularly specific to linux targets and ideally we
don't want to be adding more linuxisms to the recipe.  It is,
admittedly, not entirely obvious how we could conveniently get that
dependency added only for linux targets (since I don't think there's any
existing OVERRIDE that's helpful here) but perhaps we should find a way
to address that problem rather than just sticking it in unconditionally.

p.

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Richard Purdie]

On Thu, 2012-11-22 at 21:50 +0000, Phil Blundell wrote:
> On Thu, 2012-11-22 at 21:36 +0000, Richard Purdie wrote:
> > -DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
> > +DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"
> 
> gcc-cross isn't particularly specific to linux targets and ideally we
> don't want to be adding more linuxisms to the recipe.  It is,
> admittedly, not entirely obvious how we could conveniently get that
> dependency added only for linux targets (since I don't think there's any
> existing OVERRIDE that's helpful here) but perhaps we should find a way
> to address that problem rather than just sticking it in unconditionally.

virtual/${TARGET_OS}-headers with a suitable provider entry?

I was assuming someone who cares about non-linux wouldn't find this
particularly hard to deal with...

Cheers,

Richard

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Phil Blundell]

On Thu, 2012-11-22 at 22:02 +0000, Richard Purdie wrote:
> On Thu, 2012-11-22 at 21:50 +0000, Phil Blundell wrote:
> > On Thu, 2012-11-22 at 21:36 +0000, Richard Purdie wrote:
> > > -DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
> > > +DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"
> > 
> > gcc-cross isn't particularly specific to linux targets and ideally we
> > don't want to be adding more linuxisms to the recipe.  It is,
> > admittedly, not entirely obvious how we could conveniently get that
> > dependency added only for linux targets (since I don't think there's any
> > existing OVERRIDE that's helpful here) but perhaps we should find a way
> > to address that problem rather than just sticking it in unconditionally.
> 
> virtual/${TARGET_OS}-headers with a suitable provider entry?

I think a better approach would be to use a python fragment which
appends linux-libc-headers if ${TARGET_OS} starts with "linux".  Your
suggestion would work as well but it seems a bit ugly, and would still
be slightly annoying for targets where no such headers are required.

> I was assuming someone who cares about non-linux wouldn't find this
> particularly hard to deal with...

Well, indeed, but equally it doesn't seem especially polite to introduce
gratuitous target-specific bits into core recipes on the assumption that
someone else will run around after you cleaning them up.  If I was to
start sending patches for gcc which worked for my employer's favourite
target but broke everything else then you would presumably reject them,
and rightly so.

p.

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Richard Purdie]

On Fri, 2012-11-23 at 10:16 +0000, Phil Blundell wrote:
> On Thu, 2012-11-22 at 22:02 +0000, Richard Purdie wrote:
> > On Thu, 2012-11-22 at 21:50 +0000, Phil Blundell wrote:
> > > On Thu, 2012-11-22 at 21:36 +0000, Richard Purdie wrote:
> > > > -DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
> > > > +DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"
> > > 
> > > gcc-cross isn't particularly specific to linux targets and ideally we
> > > don't want to be adding more linuxisms to the recipe.  It is,
> > > admittedly, not entirely obvious how we could conveniently get that
> > > dependency added only for linux targets (since I don't think there's any
> > > existing OVERRIDE that's helpful here) but perhaps we should find a way
> > > to address that problem rather than just sticking it in unconditionally.
> > 
> > virtual/${TARGET_OS}-headers with a suitable provider entry?
> 
> I think a better approach would be to use a python fragment which
> appends linux-libc-headers if ${TARGET_OS} starts with "linux".  Your
> suggestion would work as well but it seems a bit ugly, and would still
> be slightly annoying for targets where no such headers are required.
>
> > I was assuming someone who cares about non-linux wouldn't find this
> > particularly hard to deal with...
> 
> Well, indeed, but equally it doesn't seem especially polite to introduce
> gratuitous target-specific bits into core recipes on the assumption that
> someone else will run around after you cleaning them up.  If I was to
> start sending patches for gcc which worked for my employer's favourite
> target but broke everything else then you would presumably reject them,
> and rightly so.

I'm not sure "gratuitous" is entirely fair, the metadata as it stands
today is fairly linux centric. I will however change this to use
anonymous python despite the performance and readability downsides since
I appear to have hit some nerve.

Cheers,

Richard

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Phil Blundell]

On Fri, 2012-11-23 at 12:01 +0000, Richard Purdie wrote:
> I'm not sure "gratuitous" is entirely fair, the metadata as it stands
> today is fairly linux centric.

For some (maybe large) parts of the metadata that's probably true, but
gcc-cross does happen to be usable on non-linux with only minor
adjustments to EXTRA_OECONF and it would be nice to keep it that way.

>I will however change this to use anonymous python despite the
>performance and readability downsides 

Thank you.

>... since I appear to have hit some nerve.

I guess you could view it that way.  I am indeed sensitive to having my
builds broken in easily-avoidable ways. 

p.

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Richard Purdie]

On Fri, 2012-11-23 at 12:16 +0000, Phil Blundell wrote:
> On Fri, 2012-11-23 at 12:01 +0000, Richard Purdie wrote:
> > I'm not sure "gratuitous" is entirely fair, the metadata as it stands
> > today is fairly linux centric.
> 
> For some (maybe large) parts of the metadata that's probably true, but
> gcc-cross does happen to be usable on non-linux with only minor
> adjustments to EXTRA_OECONF and it would be nice to keep it that way.
> 
> >I will however change this to use anonymous python despite the
> >performance and readability downsides 
> 
> Thank you.
> 
> >... since I appear to have hit some nerve.
> 
> I guess you could view it that way.  I am indeed sensitive to having my
> builds broken in easily-avoidable ways. 

I think the problem is that I can't reasonably know that you (or others)
are using the gcc-cross recipe for non-linux purposes. I've never seen
patches related to that or any other sign of it.

I now know this so I will try to account for it and the multitude of
other things I try and account for in future. You have implied this is
easily avoidable and it is, *if* you know what it is you're trying to
avoid (and can remember all of them).

Cheers,

Richard

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Otavio Salvador]

On Fri, Nov 23, 2012 at 10:16 AM, Phil Blundell <philb@gnu.org> wrote:
> On Fri, 2012-11-23 at 12:01 +0000, Richard Purdie wrote:
>> I'm not sure "gratuitous" is entirely fair, the metadata as it stands
>> today is fairly linux centric.
>
> For some (maybe large) parts of the metadata that's probably true, but
> gcc-cross does happen to be usable on non-linux with only minor
> adjustments to EXTRA_OECONF and it would be nice to keep it that way.

I am curious, what you use it for?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[McClintock Matthew-B29882]

On Thu, Nov 22, 2012 at 3:36 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> gcc-cross cannot build without linux-libc-headers but doesn't explicitly depend on
> it relying on the implied dependency through libc. With cases where pieces
> can be installed through sstate, we now need this explicit dependency to
> ensure builds with partial sstate work.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
> index 6d160d6..cde08ee 100644
> --- a/meta/recipes-devtools/gcc/gcc-cross.inc
> +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
> @@ -1,6 +1,6 @@
>  inherit cross
>
> -DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
> +DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"

How would you suggest not forcing a rebuild of all components if the
linux headers signature changes? During our normal development we
change Linux headers for things that would in no way effect gcc or
even libc. It's painful to watch a complete rebuild occur because of
this.

Just have a different recipe for headers for some components?

-M

Re: [PATCH] gcc-cross: Explicitly depend on linux-libc-headers

[Richard Purdie]

On Tue, 2012-11-27 at 20:08 +0000, McClintock Matthew-B29882 wrote:
> On Thu, Nov 22, 2012 at 3:36 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > gcc-cross cannot build without linux-libc-headers but doesn't explicitly depend on
> > it relying on the implied dependency through libc. With cases where pieces
> > can be installed through sstate, we now need this explicit dependency to
> > ensure builds with partial sstate work.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
> > index 6d160d6..cde08ee 100644
> > --- a/meta/recipes-devtools/gcc/gcc-cross.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
> > @@ -1,6 +1,6 @@
> >  inherit cross
> >
> > -DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}"
> > +DEPENDS = "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}"
> 
> How would you suggest not forcing a rebuild of all components if the
> linux headers signature changes? During our normal development we
> change Linux headers for things that would in no way effect gcc or
> even libc. It's painful to watch a complete rebuild occur because of
> this.
> 
> Just have a different recipe for headers for some components?

This is partly why our headers recipe is separate from the kernel and
other parts of the system but that doesn't sound like its enough for
you.

The signatures code can support things like adding the recipe name to
SIGGEN_EXCLUDERECIPES_ABISAFE to mark it as not being part of inter-task
dependencies so perhaps do that?

Cheers,

Richard