All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] how BR download the linux kernel now
Date: Wed, 13 Jul 2011 09:46:38 +0200	[thread overview]
Message-ID: <20110713094638.40cec50c@skate> (raw)
In-Reply-To: <CAAa76NSqWgSvUZEgtpCGvk-Ly69P9wdfSoWz1q2XC=-y7EtKFg@mail.gmail.com>

Le Tue, 12 Jul 2011 18:03:27 -0400,
raymond zhao <raymond.zhao.ml@gmail.com> a ?crit :

> I do not know the initial motive of this movement, but I prefer the
> old approach.

The motivation is to benefit from the common features of the package
infrastructure (git/svn/bzr download, common way of tracking package
construction, etc.)

> The linux kernel is a special "package". Lots of embedded projects
> (if not all of them) will start from a certain version of the kernel
> and hack the kernel from there, such as add device drivers etc. Then,
> put the source code into a local git server to do version control.
> Some people argued to use original tarball plus the patch, but it
> makes the development procedure very painful. In the old approach, it
> is very easy to hack the linux.mk to checkout the kernel source code
> directly into the output directory. But, in the new one. Looks it
> becomes more complex. The kernel is very big. Check out with the git,
> archive it to a tarball, and then extract it to the output directory
> for building will waste lots of time. Is there a official solution
> (or suggestion) for my situation?

Yes, I am currently working on extending the package infrastructure so
that any package (not only the Linux kernel, but any package) can be
sourced from an existing directory, instead of being downloaded through
git/svn/http.

I have already published preliminary versions of this work (see "[RFC]
Override source directories", posted May, 18th 2011), and I intend to
continue. The basic mechanism is working, I still have issues
implementing "make source" and "make external-deps" with this mechanism.

It'd be really nice if you could have a look at what I did to see if it
would solve your use case as well.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2011-07-13  7:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-12 20:26 [Buildroot] how BR download the linux kernel now raymond zhao
2011-07-12 20:59 ` Yann E. MORIN
2011-07-12 22:03   ` raymond zhao
2011-07-13  7:46     ` Thomas Petazzoni [this message]
2011-07-13 13:31 raymond zhao
2011-07-13 14:14 ` Thomas Petazzoni
2011-08-23 20:30 ` raymond zhao
2011-09-01  7:12   ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110713094638.40cec50c@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.