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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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