Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] linux: support "local" as download method
Date: Fri, 9 Dec 2011 20:09:26 +0100	[thread overview]
Message-ID: <20111209200926.09b1818d@skate> (raw)
In-Reply-To: <CAEvN+1hUU4Xd+BuMn+5DmdHAYx2Oue8QeruW50FLH0+LJ3PB2A@mail.gmail.com>

Le Fri, 9 Dec 2011 10:44:24 +0800,
Tzu-Jung Lee <roylee17@gmail.com> a ?crit :

> But soon I realized that our team may need another METHOD to support
> out use case.
> Have we considered IN-PLACE build alternative or option?

> 
> 
> For most of the packages, it is good enough for users/developers to
> leverage the power of buildroot to
> 
>     fetch, ..., configure, build, mkimage
> 
> However for some packages, ex: linux kernel, that a team or company
> actually works on,
> 
>    modify, configure, build, mkimage
> 
> has much higher frequency than the former case.

The "override source directory" mechanism allows this, as explained in
the blog post at http://free-electrons.com/blog/buildroot-2011-11/.

Basically, the first time you will do the build, Buildroot will do a
full copy of the Linux kernel sources to the Buildroot build directory.
But then, subsequent calls to "make linux-rebuild" will only :

 * Do a "rsync" of the build tree, so it will be very fast

 * Restart the build process (will only rebuild what you have changed)

 * Re-run the installation process

So this is exactly what you want.

Supporting "in-place" building in the infrastructure is simply not
possible. Buildring directory in the source directory cannot work,
because some packages needs to be built *twice* : once for the host,
once for the target. So we definitely need two build directories for
those packages. Of course, this is not the case for the Linux kernel,
which is always built for the target in Buildroot, but the package
infrastructure is common to all packages, so we have to take into
account this constraint.

One possibility is to support out-of-tree building, which we discussed
at the latest Buildroot meeting in Prague, see
http://lists.busybox.net/pipermail/buildroot/2011-November/047229.html.

Best 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-12-09 19:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1323255396-28263-1-git-send-email-tjlee@ambarella.com>
2011-12-07 12:09 ` [Buildroot] [PATCH] linux: support "local" as download method Tzu-Jung Lee
2011-12-08 21:30   ` Thomas Petazzoni
2011-12-09  2:44     ` Tzu-Jung Lee
2011-12-09 19:09       ` Thomas Petazzoni [this message]
2011-12-13 17:30       ` Arnout Vandecappelle

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=20111209200926.09b1818d@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox