Patchwork linux: add option to get sources from custom directory

login
register
mail settings
Submitter Richard Braun
Date Dec. 7, 2012, 9:46 a.m.
Message ID <1354873604-4304-1-git-send-email-rbraun@sceen.net>
Download mbox | patch
Permalink /patch/204439/
State Superseded
Headers show

Comments

Richard Braun - Dec. 7, 2012, 9:46 a.m.
Signed-off-by: Richard Braun <rbraun@sceen.net>
---
 linux/Config.in |   15 +++++++++++++--
 linux/linux.mk  |    3 +++
 2 files changed, 16 insertions(+), 2 deletions(-)
Richard Braun - Dec. 12, 2012, 9:46 a.m.
Ping.
Thomas Petazzoni - Dec. 12, 2012, 9:54 a.m.
Dear Richard Braun,

On Fri,  7 Dec 2012 10:46:44 +0100, Richard Braun wrote:

> diff --git a/linux/Config.in b/linux/Config.in
> index ef3b2a1..cafbe59 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -46,6 +46,12 @@ config BR2_LINUX_KERNEL_CUSTOM_TARBALL
>  	  This option allows to specify the http or ftp location of a
>  	  specific kernel source tarball
>  
> +config BR2_LINUX_KERNEL_CUSTOM_DIRECTORY
> +	bool "Custom directory"
> +	help
> +	  This option allows to specify the path of a specific kernel
> +	  source directory.
> +

This duplicates what the "source override" mechanism allows to do in a
generic way for all packages. So on one side, I'm tempted to say "no"
because I don't think it's worth having two mechanisms to achieve the
same thing, especially when the new mechanism is package-specific (what
if someone wants a custom source directory for Qt, for zlib, for
libpng, etc.).

On the other side, Linux, and bootloaders, are kind of special packages
in that very often people will have to work on them, and making this
easier might be useful.

Generally speaking, I'd like us to have an overall "vision" of how to
do development with Buildroot, rather than doing local hacks/fixes per
package to adjust one particular development workflow, which would end
up with many different hacks in various places with absolutely no
coherency.

Thomas
Richard Braun - Dec. 12, 2012, 10:14 a.m.
On Wed, Dec 12, 2012 at 10:54:18AM +0100, Thomas Petazzoni wrote:
> On the other side, Linux, and bootloaders, are kind of special packages
> in that very often people will have to work on them, and making this
> easier might be useful.

The fact that the kernel is clearly separate from the other packages in
menuconfig, and that it already provides several ways of fetching the
source makes it hard for most people to think of the override mechanism.
On the other hand, the fact that it's handled almost like any other
package makes this hack extremely easy and safe to implement. I don't
see a reason not to provide this fetching method if the others aren't
also reconsidered (otherwise I wouldn't have bothered sending it
anyway).
Arnout Vandecappelle - Dec. 18, 2012, 5:40 p.m.
On 12/12/12 11:14, Richard Braun wrote:
> On Wed, Dec 12, 2012 at 10:54:18AM +0100, Thomas Petazzoni wrote:
>> On the other side, Linux, and bootloaders, are kind of special packages
>> in that very often people will have to work on them, and making this
>> easier might be useful.
>
> The fact that the kernel is clearly separate from the other packages in
> menuconfig, and that it already provides several ways of fetching the
> source makes it hard for most people to think of the override mechanism.
> On the other hand, the fact that it's handled almost like any other
> package makes this hack extremely easy and safe to implement. I don't
> see a reason not to provide this fetching method if the others aren't
> also reconsidered (otherwise I wouldn't have bothered sending it
> anyway).

  I agree. I think that if we provide several methods of downloading in 
the menuconfig, then all SITE_METHODs should ideally be supported. In 
particular svn is probably also of interest to some people.

  Regards,
  Arnout
Richard Braun - Feb. 14, 2013, 2:32 p.m.
On Tue, Dec 18, 2012 at 06:40:23PM +0100, Arnout Vandecappelle wrote:
> On 12/12/12 11:14, Richard Braun wrote:
> >On Wed, Dec 12, 2012 at 10:54:18AM +0100, Thomas Petazzoni wrote:
> >>On the other side, Linux, and bootloaders, are kind of special packages
> >>in that very often people will have to work on them, and making this
> >>easier might be useful.
> >
> >The fact that the kernel is clearly separate from the other packages in
> >menuconfig, and that it already provides several ways of fetching the
> >source makes it hard for most people to think of the override mechanism.
> >On the other hand, the fact that it's handled almost like any other
> >package makes this hack extremely easy and safe to implement. I don't
> >see a reason not to provide this fetching method if the others aren't
> >also reconsidered (otherwise I wouldn't have bothered sending it
> >anyway).
> 
>  I agree. I think that if we provide several methods of downloading
> in the menuconfig, then all SITE_METHODs should ideally be
> supported. In particular svn is probably also of interest to some
> people.

Ping.
Thomas Petazzoni - Feb. 14, 2013, 2:46 p.m.
Dear Richard Braun,

On Thu, 14 Feb 2013 15:32:37 +0100, Richard Braun wrote:

> >  I agree. I think that if we provide several methods of downloading
> > in the menuconfig, then all SITE_METHODs should ideally be
> > supported. In particular svn is probably also of interest to some
> > people.
> 
> Ping.

Rafal Fabich has submitted "[PATCH v2] Added local directory as soure
of kernel code" today, which seems to implement what you want. If you
could test it and add your Tested-by on the patch, it would be great.

Thanks,

Thomas

Patch

diff --git a/linux/Config.in b/linux/Config.in
index ef3b2a1..cafbe59 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -46,6 +46,12 @@  config BR2_LINUX_KERNEL_CUSTOM_TARBALL
 	  This option allows to specify the http or ftp location of a
 	  specific kernel source tarball
 
+config BR2_LINUX_KERNEL_CUSTOM_DIRECTORY
+	bool "Custom directory"
+	help
+	  This option allows to specify the path of a specific kernel
+	  source directory.
+
 config BR2_LINUX_KERNEL_CUSTOM_GIT
 	bool "Custom Git tree"
 	help
@@ -56,12 +62,16 @@  endchoice
 
 config BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE
 	string "Kernel version"
-	depends on BR2_LINUX_KERNEL_CUSTOM_VERSION
+	depends on BR2_LINUX_KERNEL_CUSTOM_VERSION || BR2_LINUX_KERNEL_CUSTOM_DIRECTORY
 
 config BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
 	string "URL of custom kernel tarball"
 	depends on BR2_LINUX_KERNEL_CUSTOM_TARBALL
 
+config BR2_LINUX_KERNEL_CUSTOM_DIRECTORY_PATH
+	string "Path of custom kernel sources"
+	depends on BR2_LINUX_KERNEL_CUSTOM_DIRECTORY
+
 config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL
 	string "URL of custom Git repository"
 	depends on BR2_LINUX_KERNEL_CUSTOM_GIT
@@ -78,7 +88,8 @@  config BR2_LINUX_KERNEL_VERSION
 	string
 	default "3.6.9" if BR2_LINUX_KERNEL_3_6
 	default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
-	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
+	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION || \
+		BR2_LINUX_KERNEL_CUSTOM_DIRECTORY
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
 	default $BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT
 
diff --git a/linux/linux.mk b/linux/linux.mk
index c4bdf90..1898408 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -15,6 +15,9 @@  LINUX_SOURCE = $(notdir $(LINUX_TARBALL))
 else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_GIT),y)
 LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL))
 LINUX_SITE_METHOD = git
+else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_DIRECTORY),y)
+LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DIRECTORY_PATH))
+LINUX_SITE_METHOD = local
 else
 LINUX_SOURCE = linux-$(LINUX_VERSION).tar.bz2
 # In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order