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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core