[Buildroot] BR2_EXTERNAL Setup

Stephen Beckwith embeddedsteve at gmail.com
Thu Oct 29 16:43:19 UTC 2015


Greetings,
   I've been going through the posted slides and docs (very nice job!) and
the manual, and I'd like to seek some guidance regarding a setup using the
BR2_EXTERNAL support in BuildRoot.
    What I'm developing here is a "system" - not just a "board", this is
more of an "environment" for others to use:  consists of the Linux Kernel,
the standard packages, quite a bit of custom code (application modules,
maybe some libraries), and then third-party tools will most likely be
included as well.
     In the documentation, the "recommended" setup for the BR2_EXTERNAL
tree always starts with "board", then company, etc. . . .   Since the work
I'm doing won't be contributed back to BuildRoot (as it's strictly in-house
tools) I was wondering if the following modification makes sense.   I'd
like your feedback/view on the approach below.  Mind you, I'm building an
"environment" for users to run on the platforms.
   These platforms are similar, but have different traits.  Similar I/O
capabilities, many of the same chips, but there maybe be tweaks/patches
required due to HW Specific implementations.  Kernel configs may (probably
will be) different due to different class CPU's being used (or even
different CPU architectures).  I would like to be able to "drop in" third
party vendor tools easily.  If shared across platforms, then they go in
common, else under the specific platform.

Goals:
1)  Keep things simple - to replace/update easily, add in updated packages,
etc.
2)  Drop in 3rd party packages easily
3)  share what's common (drivers, libraries, apps) but have ability to
tweak individual platforms accordingly.  From a user point of view, it's
the same "environment" (commands, RFS layout) just some different/tweaked
commands.
4)  Whether "all" of these options show up in the Buildroot config is TBD -
some maybe optional, that's still being defined.  Would like the
flexibility to add/delete packages - dependencies are TBD as well.
5) Leverage as much of the BuildRoot build infrastructure as possible,
using simple setups.

There will be "few" of us "using" this setup (1-3 people) but many more
using the output product (the "environment") - could be 10's of folks
across the company.

I've started this external tree at "platform" - the setup maybe "overly
done" in terms the Config.in and *.mk files, there maybe ways to
consolidate this or use other Make setups. . . (I've been doing Embedded SW
for 33 years, my familiarity with make/config is "middle" - not expert, but
can poke my way around if not overly complicated).

Notes:
common:  This is code (company or 3rd party) that would be common to the
various platforms. . . This will most likely be the "bulk" of the code (80%
or more).
Since the code won't be "fetched" from anywhere, the intent was to use the
<pkg>_OVERRIDE_SRCDIR mechanism, that would do the rsync from the package
source directory to the build directory for building.

Thanks in Advance for your insights and feedback.

Regards,
Stephen


[@localhost platform]$ tree
.
├── common
│   ├── common.mk
│   ├── company
│   │   ├── company.mk
│   │   ├── Config.in
│   │   ├── pkg1
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   └── pkg2
│   │       ├── Config.in
│   │       ├── pkg1.mk
│   │       └── src
│   │           ├── Makefile
│   │           ├── platform_id.c
│   │           └── platform_id.h
│   ├── Config.in
│   ├── vendor_A
│   │   ├── Config.in
│   │   ├── pkg1
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   ├── pkg2
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   └── vendorA.mk
│   └── vendor_B
│       ├── Config.in
│       ├── pkg1
│       │   ├── Config.in
│       │   ├── pkg1.mk
│       │   └── src
│       │       ├── Makefile
│       │       ├── platform_id.c
│       │       └── platform_id.h
│       ├── pkg2
│       │   ├── Config.in
│       │   ├── pkg1.mk
│       │   └── src
│       │       ├── Makefile
│       │       ├── platform_id.c
│       │       └── platform_id.h
│       └── vendorB.mk
├── Config.in
├── platA
│   ├── busybox.config
│   ├── company
│   │   ├── company.mk
│   │   ├── Config.in
│   │   ├── pkg1
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   └── pkg2
│   │       ├── Config.in
│   │       ├── pkg1.mk
│   │       └── src
│   │           ├── Makefile
│   │           ├── platform_id.c
│   │           └── platform_id.h
│   ├── Config.in
│   ├── configs
│   │   └── platA_defconfig
│   ├── linux.config
│   ├── patches
│   │   └── 0001-drvAdd.patch
│   ├── platA.mk
│   ├── rootfs_overlay
│   ├── vendor_A
│   │   ├── Config.in
│   │   ├── pkg1
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   ├── pkg2
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   └── vendorA.mk
│   └── vendor_B
│       ├── Config.in
│       ├── pkg1
│       │   ├── Config.in
│       │   ├── pkg1.mk
│       │   └── src
│       │       ├── Makefile
│       │       ├── platform_id.c
│       │       └── platform_id.h
│       ├── pkg2
│       │   ├── Config.in
│       │   ├── pkg1.mk
│       │   └── src
│       │       ├── Makefile
│       │       ├── platform_id.c
│       │       └── platform_id.h
│       └── vendorB.mk
├── platB
│   ├── busybox.config
│   ├── company
│   │   ├── company.mk
│   │   ├── Config.in
│   │   ├── pkg1
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   └── pkg2
│   │       ├── Config.in
│   │       ├── pkg1.mk
│   │       └── src
│   │           ├── Makefile
│   │           ├── platform_id.c
│   │           └── platform_id.h
│   ├── Config.in
│   ├── configs
│   │   └── platB_defconfig
│   ├── linux.config
│   ├── patches
│   │   └── 0001-drvAdd.patch
│   ├── platB.mk
│   ├── rootfs_overlay
│   ├── vendor_A
│   │   ├── Config.in
│   │   ├── pkg1
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   ├── pkg2
│   │   │   ├── Config.in
│   │   │   ├── pkg1.mk
│   │   │   └── src
│   │   │       ├── Makefile
│   │   │       ├── platform_id.c
│   │   │       └── platform_id.h
│   │   └── vendorA.mk
│   └── vendor_B
│       ├── Config.in
│       ├── pkg1
│       │   ├── Config.in
│       │   ├── pkg1.mk
│       │   └── src
│       │       ├── Makefile
│       │       ├── platform_id.c
│       │       └── platform_id.h
│       ├── pkg2
│       │   ├── Config.in
│       │   ├── pkg1.mk
│       │   └── src
│       │       ├── Makefile
│       │       ├── platform_id.c
│       │       └── platform_id.h
│       └── vendorB.mk
└── platform.mk

54 directories, 124 files
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151029/59c8cbf6/attachment.html>


More information about the buildroot mailing list