Commits

Thomas Petazzoni committed e7035d4eb90
rtai: remove option BR2_LINUX_KERNEL_EXT_RTAI_PATCH This commit removes BR2_LINUX_KERNEL_EXT_RTAI_PATCH because this option never worked. It was added in commit 8797a9cd1fe6723db34b0c125d0d9d04e3483e8d, which added package/rtai/ and RTAI as a Linux extension. The option prompt says "Path for RTAI patch file", so let's say you specify /home/foo/bar/myrtai.patch as the value for BR2_LINUX_KERNEL_EXT_RTAI_PATCH. Then the code does: RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH)) and we have a package called 'rtai', so the normal logic of <pkg>_PATCH applies. Since the <pkg>_PATCH value does not contain ftp://, http:// or https://, the package infrastructure will try to download $(RTAI_SITE)/$(RTAI_PATCH), i.e: https://www.rtai.org/userfiles/downloads/RTAI/home/foo/bar/myrtai.patch Pretty clear that it has no chance of working. Now, let's assume an URL is used as the value of BR2_LINUX_KERNEL_EXT_RTAI_PATCH, such as http://foo.com/bar/myrtai.patch. In this case, it will be properly downloaded by the package infrastructure. But then, the following code kicks in: define RTAI_PREPARE_KERNEL $(APPLY_PATCHES) \ $(LINUX_DIR) \ $(dir $(RTAI_PATCH)) \ $(notdir $(RTAI_PATCH)) endef The value of $(dir $(RTAI_PATCH)) will be http://foo.com/bar/. How can $(APPLY_PATCHES) make use of such a stupid patch location? [Thomas: add Config.in.legacy handling, as suggested by Arnout, even if we believe that no-one could have ever used this option.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>