[Buildroot] Tesla is using Buildroot
Angelo Compagnucci
angelo.compagnucci at gmail.com
Sat May 19 11:08:04 UTC 2018
2018-05-15 22:18 GMT+02:00 Arnout Vandecappelle <arnout at mind.be>:
>
>
> On 14-05-18 20:00, Trent Piepho wrote:
>> On Sat, 2018-05-12 at 10:51 -0700, Olof Johansson wrote:
>>> On Sat, May 12, 2018 at 10:06 AM, Joseph Kogut <joseph.kogut at gmail.com> wrote:
>>>> On Sat, May 12, 2018 at 6:27 AM, Adrian Perez de Castro <aperez at igalia.com> wrote:
> [snip]
>>>> I do the same thing. The top level Makefile exports BR2_EXTERNAL="..",
>>>> there's a target for cloning and checking out a specific Buildroot
>>>> revision, then there's a wildcard pattern at the end to pass any
>>>> unrecognized targets up to Buildroot's Makefile, so things like
>>>> "linux-menuconfig" still work.
>>
>>> I liked the split of having third party software in an upstream-based
>>> separate buildroot repo, and only proprietary components in
>>> BR2_EXTERNAL. That way it's easier to separate out the portion you
>>> need to share for compliance (i.e. see current github contents), while
>>> having a place to keep confidential material, work on new
>>> configs/products/prototypes/internal uses that are not yet released,
>>> etc in the BR2_EXTERNAL. As expressed above, wrapping it with a second
>>> layer of makefiles makes it relatively easy to deal with.
>>
>> We have a top-level project with a top level Makefile that contains the
>> BR2_EXTERNAL tree. I.e., the BR2_EXTERNAL tree is the top level
>> project. Buildroot exists as a git submodule in a directory of this
>> project. We can update buildroot by pulling from upstream and rebasing
>> and can git format-patch a patch to send to the list.
>>
>> We patch buildroot if:
>> 1. We think the patch is upstreamable.
>> 2. There appears to be no reasonable way to accomplish what we want
>> otherwise.
>>
>> The top level makefile uses a pattern rule to provide a target for
>> every defconfig that exists in br2-external/configs directory. It'll
>> call buildroot's build with BR2_EXTERNAL and O set build that defconfig
>> into an output directory. Or just do a buildroot *_defconfig call but
>> not actually build.
>>
>> buildroot sets itself up so that once you go to the output directory,
>> there is a Makefile that will execute any buildroot target (menuconfig,
>> pkg-rebuild, all, etc.) with BR2_EXTERNAL configured.
>
> That's *exactly* the setup I've developed for one of my projects. I've been
> meaning to export this to a buildroot-external superproject that people could
> reuse...
Please do! I'd really would like to have a "best practice" or a sort
of boilerplate to use when setting up a new project!
Thanks!
>
> One thing though: I recently switched from git submodule to git subtree.
> Submodules are really painful to work with when there are multiple developers
> who need to change both the supermodule and submodule. I haven't yet gotten
> around to using the subtree split functionality to export the upstreamable
> changes again, but it looks pretty convenient to use.
>
> Regards,
> Arnout
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> 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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
Profile: http://it.linkedin.com/in/compagnucciangelo
More information about the buildroot
mailing list