[Buildroot] [PATCH] Adding in support for custom configurations

[Steve Calfee]

On Mon, Apr 18, 2016 at 10:14 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> On Mon, Apr 18, 2016 at 10:07:58AM -0700, Steve Calfee wrote:
>> Hi Patrick,
>>
>>
>> Couldn't you get everything you want by allowing a custom user "fred"
>> to create a symlink in your ...configs/ directory to his own custom
>> config like:
>>
>> ln -s ../custom/configs/freds_defconfig
>>
>> Then all the buildroot infrastructure will work as designed, you can
>> have your standard BR2_EXTERNAL tree and "fred" can have his own
>> custom tree. Since you won't check in the symlink and only fred's
>> development will use it, no git conflicts....?
>>
>> Regards, Steve
>
> Steve,
>
> That is a good idea.  I failed to mention one aspect that would prevent
> that from working very well.
>
> A few of the companies we work with keep a custom tree in their own
> repository (one of them SVN) and then as part of their build process
> they copy it on top of the custom tree.  They don't have a mechanism to
> maintain the symlinks because they don't actually make commits to our
> repository.
>

Hi Patrick,

I don't understand the problem, symlinks don't care if their targets
are deleted and recreated.

I was already assuming users were not putting stuff into your git tree
and stuff in yourtree/custom was someone else's repo. Having the
symlink is nice if a custom repo is actually checked out into "custom"
inside your tree.

If they must have an external repo and splat their repo on top of
custom no problem -- the only thing that won't work as planned is
save_defconfig (etc). The newly saved  configs will be properly
updated in the custom filesystem/tree, but if it is a copy, the
changes will have to be manually updated into the original (SVN) repo.

Similarly, a user could put a copy of his configs in your configs
directory and just not check them into your tree. Again a manual
update to an actual repo will be needed if it changes. But how would
having the originally proposed second "custom" external help this
problem? - if it isn't their actual repo config changes would have to
be manually updated anyway.

Regards, Steve