[Buildroot] Buildroot customizations as a git submodule?

[Buildroot] Buildroot customizations as a git submodule?

[Daniel Nyström]

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.

Thoughts or comments anyone?

[Buildroot] Buildroot customizations as a git submodule?

[Thomas Petazzoni]

Le Tue, 11 Sep 2012 16:06:12 +0200,
Daniel Nystr?m <daniel.nystrom@timeterminal.se> a ?crit :

> How do you folks on this mailing list manage your customizations on
> Buildroot?

I'm maintaining them in a branch, whose starting point is a stable
Buildroot release.

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

[Buildroot] Buildroot customizations as a git submodule?

[Arnout Vandecappelle]

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

[Buildroot] Buildroot customizations as a git submodule?

[Dmitry Golubovsky]

Daniel,

Daniel wrote:

> How do you folks on this mailing list manage your customizations on Buildroot?

I have something like this in use, although not as a git submodule but
rather as a group of git repos under Google's repo utility management
(the same utility was used in Android source tree management).

See http://gitorious.org/lfa, and specifically:

http://gitorious.org/lfa/build/trees/master - this repo contains the
necessary submakefile
http://gitorious.org/lfa/myroot/trees/master - this repo contains a
project with private packages
http://gitorious.org/lfa/lfa-manifest/trees/master - this repo
contains an XML manifest file to put things together.

At the top level it looks like a directory with three subdirs: myroot,
buildroot, and build. Technicaly it should be possible to add more
repos for custom packages to manage them under the same source tree.

All private packages are symlinked to the Buildroot tree (under
"packages"), so Buildroot sources are not disturbed. Also,
build/Build.mk does some environment manipulations to run menuconfig
over an extended config file which also includes custom packages (in a
special section).

One thing which il likely not handled well, when a custom package has
the same name as an existing package, but IMHO such situation must be
avoided anyway.

Hope this helps.

Thanks.

-- 
Dmitry Golubovsky

Anywhere on the Web