Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] What's the buildroot attitude to u-boot building?
Date: Sat, 22 Feb 2014 20:45:54 +0000 (UTC)	[thread overview]
Message-ID: <leb2a2$688$1@ger.gmane.org> (raw)
In-Reply-To: 20140222000428.77575be9@skate

On 2014-02-21, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Dear Grant Edwards,
>
> On Fri, 21 Feb 2014 14:49:43 +0000 (UTC), Grant Edwards wrote:
>
>> I messed with using buildroot for building U-Boot, and decided it was
>> better to build it outside of buildroot.  I found buildroot great for
>> building a root filesystem, but I didn't find it useful for other
>> things (like building toolchains, bootloaders, kernels, etc.).  I
>> think it makes a lot more sense to build those separately.
>
> Do you have more details about what you found unpractical in Buildroot
> to build U-Boot and your kernel? What issues did you had, or things you
> found not really nice?

First, I should have prefaced my comments by saying that was a couple
years ago, so things may be different now.

There are two main reasons I switched to building the kernel and
U-Boot outside buildroot:

1) U-Boot, the Linux kernel, and the root FS are three differnt
   "things".  The binaries are versioned and archived independently,
   they have separate part numbers, and they're distributed and
   installed independently.  Building all three of them together at
   the same time with buildroot doesn't really fit well with that.  It
   ends up wasting a lot of build time when only one of them needs to
   be built.
   
   Or, you set up three different biuldroot configs to build the three
   different things. But, using buildroot to build just the kernel, or
   just U-Boot just adds a layer of indirection and opacity over the
   simple "make menuconfig && make".

2) When doing active development, it usually wasn't simple/clear how
   to get buildroot to do a "make" in the directory I wanted it to
   after a source file had been edited.  There were several occasions
   when I thought something had been rebuilt, but it wasn't -- and
   after messing around for a while I ended up having to create source
   tarballs from my edited source files, remove the buildroot build
   tree and start over from scratch.

   Buildroot is based on the sequence:

      a) fetch tarball
      b) unpack tarball
      c) apply patches
      d) run build script
      e) run install script
      
   When you're doing development on the Kernel or U-Boot that sequence
   isn't very convenient. It's a lot simpler to (in eamcs):

      a) Edit source file(s) and hit ctrl-X ctrl-S to save changes
      b) Hit F8 to do a "make" and move the cursor to the first
         warning/error.
      
After all development is done, it might be more feasible to use
buildroot to build everything. But, when you get to that point, you've
alreay got a working source trees, configurations, and makefiles for
the kernel and U-Boot, so it's simple just to stick with them.

-- 
Grant

  reply	other threads:[~2014-02-22 20:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21  1:53 [Buildroot] What's the buildroot attitude to u-boot building? Charles Manning
2014-02-21 14:49 ` Grant Edwards
2014-02-21 23:04   ` Thomas Petazzoni
2014-02-22 20:45     ` Grant Edwards [this message]
2014-02-23  0:05       ` Mike Zick
2014-02-23 10:18       ` Thomas Petazzoni
2014-02-23 18:50         ` Grant Edwards
2014-02-23 19:56           ` Mike Zick
2014-02-21 23:13 ` Thomas Petazzoni
2014-02-24  1:33   ` Charles Manning
2014-02-24  8:37     ` Peter Korsgaard
2014-03-18  5:21       ` Thomas Petazzoni
2014-03-18  8:05         ` Peter Korsgaard

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='leb2a2$688$1@ger.gmane.org' \
    --to=grant.b.edwards@gmail.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