| Submitter | Richard Purdie |
|---|---|
| Date | Nov. 22, 2012, 9:36 p.m. |
| Message ID | <1353620179.10459.59.camel@ted> |
| Download | mbox | patch |
| Permalink | /patch/39505/ |
| State | New |
| Headers | show |
Comments
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.
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
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.
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
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.
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
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?
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
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
Patch
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
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> ---