All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erik Andersen <andersen@codepoet.org>
To: buildroot@busybox.net
Subject: [Buildroot] BSP patch
Date: Thu, 22 Mar 2007 10:30:50 -0600	[thread overview]
Message-ID: <20070322163050.GA3907@codepoet.org> (raw)
In-Reply-To: <02e901c76c0f$09244670$01c4af0a@Glamdring>

On Thu Mar 22, 2007 at 12:16:51AM +0100, Ulf Samuelsson wrote:
> He wants an easy way to configure buildroot by having a set
> of ".config" files and a way to select  *which* config file
> by doing
> 
> $ make <board>-defconfig
> 
> where the defconfig files are stored in the "configs" directory.

A reasonable thing I suppose.

> I actually have a "configs" directory as well in my private buildroot
> but I copy stuff manually to the top level.
> I think that S?ren's patch is orthogonal to my work.
> 
> 
> The BSP patch is really there to allow two different configurations
> to be built within the same buildroot directory so they can share:
> 
> * toolchain
> * root file system build directory.
> but have different configurations for linux kernel and busybox
> and eventually you may want to have different content of the root file
> system.

I agree this is a desirable thing for many situations.

> The solution is to create a new directory structure
> target_build_<arch>/<board> where everything is built.
> The patch allows pre/postfixes to this directory name.

Ok

> When I have time, I would like to be able to download kernel patches
> to this directory instead of storing the patch in the target directory.
> 
> The current linux.mk is very limited in functionality and forces
> duplication of the linux patch for each board.

I agree.  It works, but this is a rather annoying limitation.
When a company has i.e. PRODUCT20, PRODUCT21, PRODUCT22, etc,
there is no easy way to build for all of them without doing a
lot of needless duplication.

> I do not see why the same patch (size > 1 MB) should be stored 10 times
> just because I have 10 boards.

Yes, this is a weakness that should be addressed.

> The BSP patch also put some structure on where the result ends up.
> Today everything is stored in the top directory, but if you
> want to build multiple boards, then you are going to get a lot of clutter.
> 
> The BSP patch will put bootloaders, kernel and root file systems in
> binaries/<board>
> 
> S?ren also would like to separate the target build from the build
> of the root file system, so I think he supports this patch.
> 
> 
> 
> So in short, I think there is really no reason to delay either of the
> patches.

Ok.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

  reply	other threads:[~2007-03-22 16:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-21 22:24 [Buildroot] BSP patch Ulf Samuelsson
2007-03-21 22:43 ` Bernhard Fischer
2007-03-21 23:13   ` Ulf Samuelsson
2007-03-22 13:26     ` Bernhard Fischer
2007-03-22 13:53       ` Ulf Samuelsson
2007-03-22 16:40         ` Erik Andersen
2007-03-22 17:24           ` Ulf Samuelsson
2007-04-30 13:37           ` Ulf Samuelsson
2007-03-29 10:30       ` Ulf Samuelsson
2007-04-10 12:18         ` Bernhard Fischer
2007-04-10 13:22           ` Ulf Samuelsson
2007-04-12 11:02             ` Haavard Skinnemoen
2007-03-21 23:16   ` Ulf Samuelsson
2007-03-22 16:30     ` Erik Andersen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-04-16 13:57 Ulf Samuelsson
2007-02-16  0:25 [Buildroot] difference between this list and gmane? Daniel Ng
2007-02-16  9:36 ` Bernhard Fischer
2007-02-16 10:18   ` [Buildroot] BSP patch Ulf Samuelsson
2007-01-25 22:44 [Buildroot] (no subject) Ulf Samuelsson
2007-01-28 22:18 ` Bernhard Fischer
2007-01-29  0:26   ` [Buildroot] BSP patch Ulf Samuelsson

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=20070322163050.GA3907@codepoet.org \
    --to=andersen@codepoet.org \
    --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.