[Buildroot] [PATCH] Added local package support.

Tzu-Jung Lee roylee17 at gmail.com
Sun Jul 29 16:34:48 UTC 2012


On Sun, Jul 29, 2012 at 11:56 PM, Arnout Vandecappelle <arnout at mind.be> wrote:
> On 07/29/12 09:02, Avishay Orpaz wrote:
>>
>> Let me try to make my point with an example. Let's say I'm designing a
>> linux based digital camera. The software stack
>> will probably include a bunch of standard software component (kernel,
>> busybox, flash utils etc.), but there would also
>> be at least one software component that is unique to the design, and not
>> intended to be shared with other designs - for
>> example, the GUI implementation of that specific model. This is the kind
>> of software I expect to see in the "local"
>> directory. Of course this software component can be put in the "package"
>> directory, but I would think of buildroot as a
>> tool, which should not be modified and can be easily upgraded.
>
>
>  But putting it in a subdirectory 'local' within the buildroot directory
> still
> has the same problem...
>
>  As for ease of upgrading buildroot when there is a package/<company name>
> directory: Peter Korsgaard (the main buildroot maintainer) does exactly that
> at his work, and I don't think he has any issue with it.  You just need one
> additional line at the top of package/Config.in to include
> package/<company name>/Config.in
>
>
>  That said, I would also like the possibility to extend buildroot with
> "local"
> packages, board-specific files, rootfs skeletons, etc.  That gives my
> customers
> the possibility to fully separate the open source stuff from the custom
> stuff.
> (I know I'm changing my opinion here, but only idiots never change their
> mind :-)
> But then, the local directory should be completely outside the buildroot
> directory.
> And I still don't really like the automatic creation of the Config.in file.
> I'm not sure what could be the alternative, though, because as you mention
> the source-ing of a Config.in can't be done conditionally or using a
> variable
> name.  Perhaps Kconfig itself should be extended to support that?
>
>
>
>> Regarding to the comment that other files in other directories may need to
>> be customized - it's very easy to put those
>> files in any directory using make variables according to one's project
>> organization preference.
>

Cannot agree with you more!
Looks we all sought to find a way to separate the upstream /open tree
with local/closed tree.
And the main problem as you indicated is the Kconf can't be done
conditionally or using a  variable

I submit another small patch set to support the "Overlay".
It is small, because most of the customization can be done outside the
buildroot.

Regards,
Roy


More information about the buildroot mailing list