[Buildroot] [PATCH] Added local package support.

[Avishay Orpaz]

2012/7/29 Arnout Vandecappelle <arnout at mind.be>

> 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...
>

That's exactly why I made the local directory name configurable. All the
other stuff is already configurable.


>
>  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.
>>
>
>  Or better yet, define a default project directory layout that sets
> paths like BR2_LINUX_KERNEL_PATCH automatically.
>
>
>
>  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<http://www.linkedin.com/in/arnoutvandecappelle>
>
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120729/19d58db0/attachment.html>