gcc-cross: Explicitly depend on linux-libc-headers
PATCH 1/1 gcc-cross: Explicitly depend on linux-libc-headers
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.
---
meta/recipes-devtools/gcc/gcc-cross.inc +1 -1
@@ -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
meta/recipes-devtools/gcc/gcc-cross.inc line 3
Quoted 2 lines · Richard Purdie
meta/recipes-devtools/gcc/gcc-cross.inc +1
-1-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.
Quoted 10 lines · Phil Blundell
meta/recipes-devtools/gcc/gcc-cross.inc line 3
Quoted 2 lines · Richard Purdie
meta/recipes-devtools/gcc/gcc-cross.inc +1
-1-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
Quoted 12 lines · Richard Purdie
Quoted 10 lines · Phil Blundell
meta/recipes-devtools/gcc/gcc-cross.inc line 3
Quoted 2 lines · Richard Purdie
meta/recipes-devtools/gcc/gcc-cross.inc +1
-1-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.
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 23 lines · Phil Blundell
Quoted 12 lines · Richard Purdie
Quoted 10 lines · Phil Blundell
meta/recipes-devtools/gcc/gcc-cross.inc line 3
Quoted 2 lines · Richard Purdie
meta/recipes-devtools/gcc/gcc-cross.inc +1
-1-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.
Quoted 1 line
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.
Quoted 2 lines
I was assuming someone who cares about non-linux wouldn't find this particularly hard to deal with...
Quoted 6 lines
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
Quoted 2 lines · Richard Purdie
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.
Quoted 2 lines
I will however change this to use anonymous python despite the performance and readability downsides
Thank you.
Quoted 1 line
... 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.
Quoted 11 lines · Phil Blundell
Quoted 2 lines · Richard Purdie
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_OECONFand it would be nice to keep it that way.Quoted 2 lines
I will however change this to use anonymous python despite the performance and readability downsides
Quoted 6 lines
Thank you.
Quoted 1 line
... 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
Quoted 7 lines · Phil Blundell
Quoted 2 lines · Richard Purdie
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_OECONFand it would be nice to keep it that way.
I am curious, what you use it for?
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Quoted 12 lines · 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 <[email protected]>---
meta/recipes-devtools/gcc/gcc-cross.inc +0
-0
meta/recipes-devtools/gcc/gcc-cross.inc line 3
Quoted 4 lines
meta/recipes-devtools/gcc/gcc-cross.inc +1
-1@@ -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
Quoted 25 lines · On Tue, 2012-11-27 at 20:08 +0000, McClintock Matthew-B29882 wrote:
Quoted 12 lines · 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 <[email protected]>---
meta/recipes-devtools/gcc/gcc-cross.inc +0
-0meta/recipes-devtools/gcc/gcc-cross.inc line 3
Quoted 4 lines
meta/recipes-devtools/gcc/gcc-cross.inc +1
-1@@ -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.
Quoted 1 line
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