kumquat-buildroot/package/linux-headers/Config.in.host

236 lines
6.6 KiB
Plaintext
Raw Normal View History

config BR2_PACKAGE_HOST_LINUX_HEADERS
bool
comment "Kernel Header Options"
2004-10-09 07:33:05 +02:00
choice
prompt "Kernel Headers"
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL
default BR2_KERNEL_HEADERS_4_6
help
Select the version of kernel header files you wish to use.
You must select the correct set of header files to match
the kernel you intend to use on your target system.
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
config BR2_KERNEL_HEADERS_AS_KERNEL
bool "Same as kernel"
depends on BR2_LINUX_KERNEL
config BR2_KERNEL_HEADERS_3_2
bool "Linux 3.2.x kernel headers"
depends on !BR2_arc && !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
config BR2_KERNEL_HEADERS_3_4
bool "Linux 3.4.x kernel headers"
depends on !BR2_arc && !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
config BR2_KERNEL_HEADERS_3_10
bool "Linux 3.10.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
config BR2_KERNEL_HEADERS_3_12
bool "Linux 3.12.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
config BR2_KERNEL_HEADERS_3_14
bool "Linux 3.14.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
config BR2_KERNEL_HEADERS_3_18
bool "Linux 3.18.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
config BR2_KERNEL_HEADERS_3_19
bool "Linux 3.19.x kernel headers"
depends on BR2_DEPRECATED_SINCE_2015_08
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_19
config BR2_KERNEL_HEADERS_4_0
bool "Linux 4.0.x kernel headers"
depends on BR2_DEPRECATED_SINCE_2015_08
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_0
config BR2_KERNEL_HEADERS_4_1
bool "Linux 4.1.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
config BR2_KERNEL_HEADERS_4_2
bool "Linux 4.2.x kernel headers"
depends on BR2_DEPRECATED_SINCE_2016_02
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_2
config BR2_KERNEL_HEADERS_4_3
bool "Linux 4.3.x kernel headers"
depends on BR2_DEPRECATED_SINCE_2016_05
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_3
config BR2_KERNEL_HEADERS_4_4
bool "Linux 4.4.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
config BR2_KERNEL_HEADERS_4_5
bool "Linux 4.5.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
config BR2_KERNEL_HEADERS_4_6
bool "Linux 4.6.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_6
config BR2_KERNEL_HEADERS_VERSION
bool "Manually specified Linux version"
endchoice
config BR2_DEFAULT_KERNEL_VERSION
string "linux version"
depends on BR2_KERNEL_HEADERS_VERSION
help
Specify the version you want to use.
E.G.: 3.6.10
choice
bool "Custom kernel headers series"
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
depends on BR2_KERNEL_HEADERS_VERSION || BR2_KERNEL_HEADERS_AS_KERNEL
default BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD
help
Set to the kernel headers series you manually set above.
This is used to hide/show some packages that have strict
requirements on the version of kernel headers.
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_6
bool "4.6.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_6
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_5
bool "4.5.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4
bool "4.4.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_3
bool "4.3.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_3
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2
bool "4.2.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_2
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1
bool "4.1.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_0
bool "4.0.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_0
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_19
bool "3.19.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_19
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_18
bool "3.18.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_17
bool "3.17.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_16
bool "3.16.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_16
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_15
bool "3.15.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14
bool "3.14.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13
bool "3.13.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_13
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12
bool "3.12.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_11
bool "3.11.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_10
bool "3.10.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_9
bool "3.9.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_9
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_8
bool "3.8.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_7
bool "3.7.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_6
bool "3.6.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_6
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_5
bool "3.5.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_5
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_4
bool "3.4.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_3
bool "3.3.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_3
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_2
bool "3.2.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_1
bool "3.1.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_0
bool "3.0.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD
bool "2.6.x"
endchoice
config BR2_DEFAULT_KERNEL_HEADERS
string
default "3.2.80" if BR2_KERNEL_HEADERS_3_2
default "3.4.112" if BR2_KERNEL_HEADERS_3_4
default "3.10.101" if BR2_KERNEL_HEADERS_3_10
default "3.12.59" if BR2_KERNEL_HEADERS_3_12
default "3.14.70" if BR2_KERNEL_HEADERS_3_14
default "3.18.33" if BR2_KERNEL_HEADERS_3_18
default "3.19.8" if BR2_KERNEL_HEADERS_3_19
default "4.0.9" if BR2_KERNEL_HEADERS_4_0
default "4.1.24" if BR2_KERNEL_HEADERS_4_1
default "4.2.8" if BR2_KERNEL_HEADERS_4_2
default "4.3.6" if BR2_KERNEL_HEADERS_4_3
default "4.4.11" if BR2_KERNEL_HEADERS_4_4
default "4.5.5" if BR2_KERNEL_HEADERS_4_5
default "4.6.1" if BR2_KERNEL_HEADERS_4_6
default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION