Kconfig and toolchain dependencies
Right now, we don't have a good way to encode toolchain dependencies in Kconfig. This makes it hard to add optional features which depend on newer toolchain features.
If we just add them, then it breaks all*config and randconfig on platforms with the older toolchains unless the user manually adds exclusion rules. This is bad for testing.
It seems relatively straightforward to do if we were to manifest some CONFIG_ variables based on the target toolchain, e.g.
CONFIG_GCC=0x040601
... and perhaps do other tests. I suspect we would run the tests less frequently than what we do right now with the tests embedded in the Makefile.
Does anyone have a feel for if this would be a good addition, and if so where it best fits into the chain?
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 11 lines · H. Peter Anvin
It seems relatively straightforward to do if we were to manifest some
CONFIG_variables based on the target toolchain, e.g.
CONFIG_GCC=0x040601... and perhaps do other tests. I suspect we would run the tests less frequently than what we do right now with the tests embedded in the
Makefile.Does anyone have a feel for if this would be a good addition, and if so where it best fits into the chain?
This seems like a *great* idea. Unfortunately, a quick look at the implementation of kbuild suggests that it doesn't currently implement numeric comparisons (<, <=, >, >=), only equality (= and !=). Most of the time, a Kconfig file will want to write "depends GCC >= some_version".
Looking at scripts/kconfig/expr.c, it doesn't look that hard to add, though.
- Josh Triplett
Quoted 4 lines · Josh Triplett
Quoted 3 lines
Does anyone have a feel for if this would be a good addition, and if so where it best fits into the chain?
Quoted 9 lines
This seems like a *great* idea. Unfortunately, a quick look at the implementation of kbuild suggests that it doesn't currently implement numeric comparisons (<, <=, >, >=), only equality (= and !=). Most of the time, a
Kconfigfile will want to write "depends GCC >=some_version".Looking at
scripts/kconfig/expr.c, it doesn't look that hard to add, though.
Range dependencies are probably useful in their own right, too.
-hpa
Dne 3.2.2012 22:29, H. Peter Anvin napsal(a):
Quoted 4 lines
Right now, we don't have a good way to encode toolchain dependencies in
Kconfig. This makes it hard to add optional features which depend on newer toolchain features.
Quoted 8 lines
If we just add them, then it breaks all*config and randconfig on platforms with the older toolchains unless the user manually adds exclusion rules. This is bad for testing.
It seems relatively straightforward to do if we were to manifest some
CONFIG_variables based on the target toolchain, e.g.
CONFIG_GCC=0x040601
(sorry for the late reply)
It would be a bit tricky, because the toolchain version depends also on CONFIG_CROSS_COMPILE. So Kconfig would need to know the semantics of CONFIG_CROSS_COMPILE and CONFIG_GCC and the dependency of the latter on the former.
Michal
Quoted 14 lines · Michal Marek
Dne 3.2.2012 22:29, H. Peter Anvin napsal(a):
Quoted 4 lines
Right now, we don't have a good way to encode toolchain dependencies in
Kconfig. This makes it hard to add optional features which depend on newer toolchain features.Quoted 8 lines
If we just add them, then it breaks all*config and randconfig on platforms with the older toolchains unless the user manually adds exclusion rules. This is bad for testing.
It seems relatively straightforward to do if we were to manifest some
CONFIG_variables based on the target toolchain, e.g.
CONFIG_GCC=0x040601
Quoted 8 lines
(sorry for the late reply)
It would be a bit tricky, because the toolchain version depends also on
CONFIG_CROSS_COMPILE. SoKconfigwould need to know the semantics ofCONFIG_CROSS_COMPILEandCONFIG_GCCand the dependency of the latter on the former.Michal
Either way it would mean having to regenerate the config when the toolchain changes.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.