linux: add option to get sources from custom directory

Signed-off-by: Richard Braun <rbraun@sceen.net>
---
 linux/Config.in |   15 +++++++++++++--
 linux/linux.mk  |    3 +++
 2 files changed, 16 insertions(+), 2 deletions(-)

Ping.

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

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).

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

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.

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