Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot customizations as a git submodule?
Date: Tue, 11 Sep 2012 21:14:41 +0200	[thread overview]
Message-ID: <504F8DA1.3040405@mind.be> (raw)
In-Reply-To: <CAHQn0kgXzCNf560jUw_AF82tSuOpHqUWu04yfisxf2Ac1iYPdQ@mail.gmail.com>

On 09/11/12 16:06, Daniel Nystr?m wrote:
> How do you folks on this mailing list manage your customizations on Buildroot?
>
> I was thinking maybe I could keep all my customizations as a git
> submodule residing in board/<company>/<project>?
>
> Can I add new software packages without touching the original BR
> source files or directories? How about defconfigs?
>
> It would be really awesome if this could be achieved so one did not
> have to make changes to BR at all.

  My usual approach is the following:

- packages and other changes which can be upstreamed I apply directly to the
buildroot tree (in a project-specific branch);

- private (closed source) packages, board-specific kernel patches, config files
etc. are kept out of tree, and included using the local.mk mechanism.

  I don't bother with Config.in for the private packages, because there is
usually nothing to configure there.  The BR2_PACKAGE_XXX symbols are enabled
unconditionally in the project's local.mk file.

  The buildroot defconfig is also kept in the project directory, as well
as a Makefile that uses this defconfig by calling 'make defconfig' with
the BR2_DEFCONFIG=... option.  If the project uses several buildroot
configurations (it usually does), then I generate them in different output
directories.

  I'm planning to post some patch to facilitate this once it becomes a bit
more clear what is generic.


  Note that this only applies when you don't share packages between different
projects.  If you do, then you do need Config.in and there's no other option
than to modify buildroot itself.  There is a patch floating on the list to
support out-of-tree Config.in inclusion, but it was rejected.


  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  parent reply	other threads:[~2012-09-11 19:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 14:06 [Buildroot] Buildroot customizations as a git submodule? Daniel Nyström
2012-09-11 14:26 ` Thomas Petazzoni
2012-09-11 19:14 ` Arnout Vandecappelle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-09-11 14:26 Dmitry Golubovsky

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=504F8DA1.3040405@mind.be \
    --to=arnout@mind.be \
    --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