NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
b2c043b29a
kumquat-buildroot/package/linux-tools/linux-tool-selftests.mk.in

47 lines
1.4 KiB
Makefile
Raw Normal View History

linux: build and install kernel selftests This patch adds the ability to compile and install the kernel selftests into the target at /usr/lib/kselftests. The rationale behind /usr/lib is that the selftests have subdirectories where they are installed which makes them unsuitable to be placed in /usr/sbin as this would result in /usr/sbin/kselftests/x/y/z. While the selftests aren't libraries either, they don't achieve much as a standalone binary so they can be considered to be a 'library of tests' making /usr/lib sensible. The selftests require that the kernel headers be installed into the kernel build tree as some of the selftests have a hardcoded CFLAGS to include kernel headers (CFLAGS += -I../../../../usr/include/). This is most easily achieved by using the make ... headers_install inside the kernel build dir. This is likely to be a rarely used debugging/performance feature for development and unlikely to be used in a production configuration. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Thomas: - remove bash as a build dependency, it is only a runtime dependency. - fix typo in the Config.in help text, and rewrap - add missing 'depends on BR2_USE_MMU' dependency for the comment.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-16 04:26:33 +01:00
################################################################################
#
# selftests
#
################################################################################
LINUX_TOOLS += selftests
ifeq ($(KERNEL_ARCH),x86_64)
SELFTESTS_ARCH=x86
else
ifeq ($(KERNEL_ARCH),i386)
SELFTESTS_ARCH=x86
else
SELFTESTS_ARCH=$(KERNEL_ARCH)
endif
endif
SELFTESTS_DEPENDENCIES = libcap-ng popt
SELFTESTS_MAKE_FLAGS = \
$(LINUX_MAKE_FLAGS) \
ARCH=$(SELFTESTS_ARCH)
# O must be redefined here to overwrite the one used by Buildroot for
linux/tools: make it a real, separate package The kernel source tree also contains the sources for various userland tools, of which cpupower, perf or selftests. Currently, we have support for building those tools as part of the kernel build procedure. This looked the correct thing to do so far, because, well, they *are* part of the kernel source tree and some really have to be the same version as the kernel that will run. However, this is causing quite a non-trivial-to-break circular dependency in some configurations. For example, this defconfig fails to build (similar to the one reported by Paul): BR2_arm=y BR2_cortex_a7=y BR2_ARM_FPU_NEON_VFPV4=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f" BR2_LINUX_KERNEL_DEFCONFIG="bcm2709" BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y BR2_PACKAGE_CRYPTODEV=y BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_LIBCURL=y This causes a circular dependency, as explained by Thomas: - When libcurl is enabled, systemd depends on it - When OpenSSL is enabled, obviously, will use it for SSL support - When cryptodev-linux is enabled, OpenSSL will depend on it to use crypto accelerators supported in the kernel via cryptodev-linux. - cryptodev-linux being a kernel module, it depends on linux - linux by itself (the kernel) does not depend on pciutils, but the linux tool "cpupower" (managed in linux-tool-cpupower) depends on pciutils - pciutils depends on udev when available - udev is provided by systemd. And indeed, during the build, we can see that make warns (it's only reported as a *warning*, not as an actual error): [...] make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured <- cryptodev-linux dependency dropped. >>> openssl 1.0.2h Downloading [...] So the build fails later on, when openssl is actually built: eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory compilation terminated. <builtin>: recipe for target 'eng_cryptodev.o' failed Furthermore, graph-depends also detects the circular dependency, but treats it as a hard-error: Recursion detected for : cryptodev-linux which is a dependency of: openssl which is a dependency of: libcurl which is a dependency of: systemd which is a dependency of: udev which is a dependency of: pciutils which is a dependency of: linux which is a dependency of: cryptodev-linux Makefile:738: recipe for target 'graph-depends' failed Of course, there is no way to break the loop without losing functionality in either one of the involved packages *and* keep our infrastructure and packages as-is. The only solution is to break the loop at the linux-tools level, by moving them away into their own package, so that the linux package will no longer have the opportunity to depend on another package via a dependency of one the tools. All three linux tools are thus moved away to their own package. The package infrastructure only knows of three types of packages: those in package/ , in boot/ , in toolchain/ and the one in linux/ . So we create that new linux-tools package in package/ so that we don't have to fiddle with yet another special case in the infra. Still, we want its configure options to appear in the kernel's sub-menu. So, we make it a prompt-less package, with only the tools visible as options of that package, but without the usual dependency on their master symbol; they only depend on the Linux kernel. Furthermore, because the kernel is such a huge pile of code, we would not be very happy to extract it a second time just for the sake of a few tools. We can't extract only the tools/ sub-directory from the kernel source either, because some tools have hard-coded path to includes from the kernel (arch and stuff). Instead, we just use the linux source tree as our own build tree, and ensure the linux tree is extracted and patched before linux-tools is configured and built. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Paul Ashford <paul.ashford@zurria.co.uk> [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
# out of tree build. We build the selftests in $(LINUX_DIR)/tools/selftests and
# not just $(LINUX_DIR) so that it isn't built in the root directory of the kernel
linux: build and install kernel selftests This patch adds the ability to compile and install the kernel selftests into the target at /usr/lib/kselftests. The rationale behind /usr/lib is that the selftests have subdirectories where they are installed which makes them unsuitable to be placed in /usr/sbin as this would result in /usr/sbin/kselftests/x/y/z. While the selftests aren't libraries either, they don't achieve much as a standalone binary so they can be considered to be a 'library of tests' making /usr/lib sensible. The selftests require that the kernel headers be installed into the kernel build tree as some of the selftests have a hardcoded CFLAGS to include kernel headers (CFLAGS += -I../../../../usr/include/). This is most easily achieved by using the make ... headers_install inside the kernel build dir. This is likely to be a rarely used debugging/performance feature for development and unlikely to be used in a production configuration. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Thomas: - remove bash as a build dependency, it is only a runtime dependency. - fix typo in the Config.in help text, and rewrap - add missing 'depends on BR2_USE_MMU' dependency for the comment.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-16 04:26:33 +01:00
# sources.
#
# The headers_install step here is important as some kernel selftests use a
# hardcoded CFLAGS to find kernel headers e.g:
# CFLAGS += -I../../../../usr/include/
# The headers_install target will install the kernel headers locally inside
# the Linux build dir
define SELFTESTS_BUILD_CMDS
linux/tools: make it a real, separate package The kernel source tree also contains the sources for various userland tools, of which cpupower, perf or selftests. Currently, we have support for building those tools as part of the kernel build procedure. This looked the correct thing to do so far, because, well, they *are* part of the kernel source tree and some really have to be the same version as the kernel that will run. However, this is causing quite a non-trivial-to-break circular dependency in some configurations. For example, this defconfig fails to build (similar to the one reported by Paul): BR2_arm=y BR2_cortex_a7=y BR2_ARM_FPU_NEON_VFPV4=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f" BR2_LINUX_KERNEL_DEFCONFIG="bcm2709" BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y BR2_PACKAGE_CRYPTODEV=y BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_LIBCURL=y This causes a circular dependency, as explained by Thomas: - When libcurl is enabled, systemd depends on it - When OpenSSL is enabled, obviously, will use it for SSL support - When cryptodev-linux is enabled, OpenSSL will depend on it to use crypto accelerators supported in the kernel via cryptodev-linux. - cryptodev-linux being a kernel module, it depends on linux - linux by itself (the kernel) does not depend on pciutils, but the linux tool "cpupower" (managed in linux-tool-cpupower) depends on pciutils - pciutils depends on udev when available - udev is provided by systemd. And indeed, during the build, we can see that make warns (it's only reported as a *warning*, not as an actual error): [...] make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured <- cryptodev-linux dependency dropped. >>> openssl 1.0.2h Downloading [...] So the build fails later on, when openssl is actually built: eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory compilation terminated. <builtin>: recipe for target 'eng_cryptodev.o' failed Furthermore, graph-depends also detects the circular dependency, but treats it as a hard-error: Recursion detected for : cryptodev-linux which is a dependency of: openssl which is a dependency of: libcurl which is a dependency of: systemd which is a dependency of: udev which is a dependency of: pciutils which is a dependency of: linux which is a dependency of: cryptodev-linux Makefile:738: recipe for target 'graph-depends' failed Of course, there is no way to break the loop without losing functionality in either one of the involved packages *and* keep our infrastructure and packages as-is. The only solution is to break the loop at the linux-tools level, by moving them away into their own package, so that the linux package will no longer have the opportunity to depend on another package via a dependency of one the tools. All three linux tools are thus moved away to their own package. The package infrastructure only knows of three types of packages: those in package/ , in boot/ , in toolchain/ and the one in linux/ . So we create that new linux-tools package in package/ so that we don't have to fiddle with yet another special case in the infra. Still, we want its configure options to appear in the kernel's sub-menu. So, we make it a prompt-less package, with only the tools visible as options of that package, but without the usual dependency on their master symbol; they only depend on the Linux kernel. Furthermore, because the kernel is such a huge pile of code, we would not be very happy to extract it a second time just for the sake of a few tools. We can't extract only the tools/ sub-directory from the kernel source either, because some tools have hard-coded path to includes from the kernel (arch and stuff). Instead, we just use the linux source tree as our own build tree, and ensure the linux tree is extracted and patched before linux-tools is configured and built. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Paul Ashford <paul.ashford@zurria.co.uk> [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
$(TARGET_MAKE_ENV) $(MAKE1) -C $(LINUX_DIR) $(SELFTESTS_MAKE_FLAGS) \
linux: build and install kernel selftests This patch adds the ability to compile and install the kernel selftests into the target at /usr/lib/kselftests. The rationale behind /usr/lib is that the selftests have subdirectories where they are installed which makes them unsuitable to be placed in /usr/sbin as this would result in /usr/sbin/kselftests/x/y/z. While the selftests aren't libraries either, they don't achieve much as a standalone binary so they can be considered to be a 'library of tests' making /usr/lib sensible. The selftests require that the kernel headers be installed into the kernel build tree as some of the selftests have a hardcoded CFLAGS to include kernel headers (CFLAGS += -I../../../../usr/include/). This is most easily achieved by using the make ... headers_install inside the kernel build dir. This is likely to be a rarely used debugging/performance feature for development and unlikely to be used in a production configuration. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Thomas: - remove bash as a build dependency, it is only a runtime dependency. - fix typo in the Config.in help text, and rewrap - add missing 'depends on BR2_USE_MMU' dependency for the comment.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-16 04:26:33 +01:00
headers_install
linux/tools: make it a real, separate package The kernel source tree also contains the sources for various userland tools, of which cpupower, perf or selftests. Currently, we have support for building those tools as part of the kernel build procedure. This looked the correct thing to do so far, because, well, they *are* part of the kernel source tree and some really have to be the same version as the kernel that will run. However, this is causing quite a non-trivial-to-break circular dependency in some configurations. For example, this defconfig fails to build (similar to the one reported by Paul): BR2_arm=y BR2_cortex_a7=y BR2_ARM_FPU_NEON_VFPV4=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f" BR2_LINUX_KERNEL_DEFCONFIG="bcm2709" BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y BR2_PACKAGE_CRYPTODEV=y BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_LIBCURL=y This causes a circular dependency, as explained by Thomas: - When libcurl is enabled, systemd depends on it - When OpenSSL is enabled, obviously, will use it for SSL support - When cryptodev-linux is enabled, OpenSSL will depend on it to use crypto accelerators supported in the kernel via cryptodev-linux. - cryptodev-linux being a kernel module, it depends on linux - linux by itself (the kernel) does not depend on pciutils, but the linux tool "cpupower" (managed in linux-tool-cpupower) depends on pciutils - pciutils depends on udev when available - udev is provided by systemd. And indeed, during the build, we can see that make warns (it's only reported as a *warning*, not as an actual error): [...] make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured <- cryptodev-linux dependency dropped. >>> openssl 1.0.2h Downloading [...] So the build fails later on, when openssl is actually built: eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory compilation terminated. <builtin>: recipe for target 'eng_cryptodev.o' failed Furthermore, graph-depends also detects the circular dependency, but treats it as a hard-error: Recursion detected for : cryptodev-linux which is a dependency of: openssl which is a dependency of: libcurl which is a dependency of: systemd which is a dependency of: udev which is a dependency of: pciutils which is a dependency of: linux which is a dependency of: cryptodev-linux Makefile:738: recipe for target 'graph-depends' failed Of course, there is no way to break the loop without losing functionality in either one of the involved packages *and* keep our infrastructure and packages as-is. The only solution is to break the loop at the linux-tools level, by moving them away into their own package, so that the linux package will no longer have the opportunity to depend on another package via a dependency of one the tools. All three linux tools are thus moved away to their own package. The package infrastructure only knows of three types of packages: those in package/ , in boot/ , in toolchain/ and the one in linux/ . So we create that new linux-tools package in package/ so that we don't have to fiddle with yet another special case in the infra. Still, we want its configure options to appear in the kernel's sub-menu. So, we make it a prompt-less package, with only the tools visible as options of that package, but without the usual dependency on their master symbol; they only depend on the Linux kernel. Furthermore, because the kernel is such a huge pile of code, we would not be very happy to extract it a second time just for the sake of a few tools. We can't extract only the tools/ sub-directory from the kernel source either, because some tools have hard-coded path to includes from the kernel (arch and stuff). Instead, we just use the linux source tree as our own build tree, and ensure the linux tree is extracted and patched before linux-tools is configured and built. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Paul Ashford <paul.ashford@zurria.co.uk> [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
$(TARGET_MAKE_ENV) $(MAKE1) -C $(LINUX_DIR)/tools/testing/selftests \
$(SELFTESTS_MAKE_FLAGS) O=$(LINUX_DIR)/tools/testing/selftests
linux: build and install kernel selftests This patch adds the ability to compile and install the kernel selftests into the target at /usr/lib/kselftests. The rationale behind /usr/lib is that the selftests have subdirectories where they are installed which makes them unsuitable to be placed in /usr/sbin as this would result in /usr/sbin/kselftests/x/y/z. While the selftests aren't libraries either, they don't achieve much as a standalone binary so they can be considered to be a 'library of tests' making /usr/lib sensible. The selftests require that the kernel headers be installed into the kernel build tree as some of the selftests have a hardcoded CFLAGS to include kernel headers (CFLAGS += -I../../../../usr/include/). This is most easily achieved by using the make ... headers_install inside the kernel build dir. This is likely to be a rarely used debugging/performance feature for development and unlikely to be used in a production configuration. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Thomas: - remove bash as a build dependency, it is only a runtime dependency. - fix typo in the Config.in help text, and rewrap - add missing 'depends on BR2_USE_MMU' dependency for the comment.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-16 04:26:33 +01:00
endef
define SELFTESTS_INSTALL_TARGET_CMDS
linux/tools: make it a real, separate package The kernel source tree also contains the sources for various userland tools, of which cpupower, perf or selftests. Currently, we have support for building those tools as part of the kernel build procedure. This looked the correct thing to do so far, because, well, they *are* part of the kernel source tree and some really have to be the same version as the kernel that will run. However, this is causing quite a non-trivial-to-break circular dependency in some configurations. For example, this defconfig fails to build (similar to the one reported by Paul): BR2_arm=y BR2_cortex_a7=y BR2_ARM_FPU_NEON_VFPV4=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f" BR2_LINUX_KERNEL_DEFCONFIG="bcm2709" BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y BR2_PACKAGE_CRYPTODEV=y BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_LIBCURL=y This causes a circular dependency, as explained by Thomas: - When libcurl is enabled, systemd depends on it - When OpenSSL is enabled, obviously, will use it for SSL support - When cryptodev-linux is enabled, OpenSSL will depend on it to use crypto accelerators supported in the kernel via cryptodev-linux. - cryptodev-linux being a kernel module, it depends on linux - linux by itself (the kernel) does not depend on pciutils, but the linux tool "cpupower" (managed in linux-tool-cpupower) depends on pciutils - pciutils depends on udev when available - udev is provided by systemd. And indeed, during the build, we can see that make warns (it's only reported as a *warning*, not as an actual error): [...] make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured <- cryptodev-linux dependency dropped. >>> openssl 1.0.2h Downloading [...] So the build fails later on, when openssl is actually built: eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory compilation terminated. <builtin>: recipe for target 'eng_cryptodev.o' failed Furthermore, graph-depends also detects the circular dependency, but treats it as a hard-error: Recursion detected for : cryptodev-linux which is a dependency of: openssl which is a dependency of: libcurl which is a dependency of: systemd which is a dependency of: udev which is a dependency of: pciutils which is a dependency of: linux which is a dependency of: cryptodev-linux Makefile:738: recipe for target 'graph-depends' failed Of course, there is no way to break the loop without losing functionality in either one of the involved packages *and* keep our infrastructure and packages as-is. The only solution is to break the loop at the linux-tools level, by moving them away into their own package, so that the linux package will no longer have the opportunity to depend on another package via a dependency of one the tools. All three linux tools are thus moved away to their own package. The package infrastructure only knows of three types of packages: those in package/ , in boot/ , in toolchain/ and the one in linux/ . So we create that new linux-tools package in package/ so that we don't have to fiddle with yet another special case in the infra. Still, we want its configure options to appear in the kernel's sub-menu. So, we make it a prompt-less package, with only the tools visible as options of that package, but without the usual dependency on their master symbol; they only depend on the Linux kernel. Furthermore, because the kernel is such a huge pile of code, we would not be very happy to extract it a second time just for the sake of a few tools. We can't extract only the tools/ sub-directory from the kernel source either, because some tools have hard-coded path to includes from the kernel (arch and stuff). Instead, we just use the linux source tree as our own build tree, and ensure the linux tree is extracted and patched before linux-tools is configured and built. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Paul Ashford <paul.ashford@zurria.co.uk> [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
$(TARGET_MAKE_ENV) $(MAKE1) -C $(LINUX_DIR)/tools/testing/selftests \
$(SELFTESTS_MAKE_FLAGS) O=$(LINUX_DIR)/tools/testing/selftests \
linux: build and install kernel selftests This patch adds the ability to compile and install the kernel selftests into the target at /usr/lib/kselftests. The rationale behind /usr/lib is that the selftests have subdirectories where they are installed which makes them unsuitable to be placed in /usr/sbin as this would result in /usr/sbin/kselftests/x/y/z. While the selftests aren't libraries either, they don't achieve much as a standalone binary so they can be considered to be a 'library of tests' making /usr/lib sensible. The selftests require that the kernel headers be installed into the kernel build tree as some of the selftests have a hardcoded CFLAGS to include kernel headers (CFLAGS += -I../../../../usr/include/). This is most easily achieved by using the make ... headers_install inside the kernel build dir. This is likely to be a rarely used debugging/performance feature for development and unlikely to be used in a production configuration. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Thomas: - remove bash as a build dependency, it is only a runtime dependency. - fix typo in the Config.in help text, and rewrap - add missing 'depends on BR2_USE_MMU' dependency for the comment.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-16 04:26:33 +01:00
INSTALL_PATH=$(TARGET_DIR)/usr/lib/kselftests install
endef
Reference in New Issue Copy Permalink