[Buildroot] Any way to override .config settings?

[Buildroot] Any way to override .config settings?

[Charles Manning]

Hi buildrooters

I need to be able to build a system from an svn repository using a
bunch of different revisions for different elements. For example, I
might want to use the kernel at r 1234, u-boot at r 4567 and the
rootfs+apps at r 3344.

Now I could achieve this by going into the .config with menuconfig and
changing the config, but I would prefer to be able to have a file of
revisions to use and have buildroot pick up those revision symbols
instead.

I guess there are a few ways this could be handled:

1) Is there a built in mechanism in buildroot to include extra symbols
and override those in .config?

2) Run my own script that nobbles the .config using sed etc.

Is there something built in to buildroot that will do this?

Thanks

Charles

[Buildroot] Any way to override .config settings?

[Arnout Vandecappelle]

On 19/12/12 23:20, Charles Manning wrote:
> I need to be able to build a system from an svn repository using a
> bunch of different revisions for different elements. For example, I
> might want to use the kernel at r 1234, u-boot at r 4567 and the
> rootfs+apps at r 3344.

  Uh? Sounds like a horrible idea to me.


> Now I could achieve this by going into the .config with menuconfig and
> changing the config, but I would prefer to be able to have a file of
> revisions to use and have buildroot pick up those revision symbols
> instead.

  I don't see the relation between the .config and svn revisions.


> I guess there are a few ways this could be handled:
>
> 1) Is there a built in mechanism in buildroot to include extra symbols
> and override those in .config?

  Yes, the package override file: BR2_PACKAGE_OVERRIDE_FILE, defaults to 
$(TOPDIR)/local.mk. I use this to include a bunch of project-specific .mk 
files that add packages without requiring a Config.in.


  Regards,
  Arnout

> 2) Run my own script that nobbles the .config using sed etc.
>
> Is there something built in to buildroot that will do this?
>
> Thanks
>
> Charles



-- 
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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Any way to override .config settings?

[Charles Manning]

On Thu, Dec 20, 2012 at 1:04 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 19/12/12 23:20, Charles Manning wrote:
>>
>> I need to be able to build a system from an svn repository using a
>> bunch of different revisions for different elements. For example, I
>> might want to use the kernel at r 1234, u-boot at r 4567 and the
>> rootfs+apps at r 3344.
>
>
>  Uh? Sounds like a horrible idea to me.

Why does it sound like a terrible idea?


>
>
>
>> Now I could achieve this by going into the .config with menuconfig and
>> changing the config, but I would prefer to be able to have a file of
>> revisions to use and have buildroot pick up those revision symbols
>> instead.
>
>
>  I don't see the relation between the .config and svn revisions.

Well svn revisions are useful to me with the changes I have made to
fetch linux from a custom location. I have not submitted that patch
yet. The same would apply for a git revison.

We want to lock the versions we build into releases or use a different
release for experimental reasons.  Overriding is sometimes less
intrusive than changing the .config.


>
>
>
>> I guess there are a few ways this could be handled:
>>
>> 1) Is there a built in mechanism in buildroot to include extra symbols
>> and override those in .config?
>
>
>  Yes, the package override file: BR2_PACKAGE_OVERRIDE_FILE, defaults to
> $(TOPDIR)/local.mk. I use this to include a bunch of project-specific .mk
> files that add packages without requiring a Config.in.

In a separate thread to this, I submitted a patch that follows the
package overriding idea to override the config

>
>
>  Regards,
>  Arnout
>
>
>> 2) Run my own script that nobbles the .config using sed etc.
>>
>> Is there something built in to buildroot that will do this?
>>
>> Thanks
>>
>> Charles
>
>
>
>
> --
> 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
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Any way to override .config settings?

[Arnout Vandecappelle]

On 20/12/12 01:13, Charles Manning wrote:
> On Thu, Dec 20, 2012 at 1:04 PM, Arnout Vandecappelle<arnout@mind.be>  wrote:
>> On 19/12/12 23:20, Charles Manning wrote:
>>>
>>> I need to be able to build a system from an svn repository using a
>>> bunch of different revisions for different elements. For example, I
>>> might want to use the kernel at r 1234, u-boot at r 4567 and the
>>> rootfs+apps at r 3344.
>>
>>
>>   Uh? Sounds like a horrible idea to me.
>
> Why does it sound like a terrible idea?

  I thought you meant the buildroot directories would be at different 
versions. But you just want to override the 
BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION, that's OK of course.

[snip]
>>> 1) Is there a built in mechanism in buildroot to include extra symbols
>>> and override those in .config?
>>
>>
>>   Yes, the package override file: BR2_PACKAGE_OVERRIDE_FILE, defaults to
>> $(TOPDIR)/local.mk. I use this to include a bunch of project-specific .mk
>> files that add packages without requiring a Config.in.
>
> In a separate thread to this, I submitted a patch that follows the
> package overriding idea to override the config

  Since it does exactly the same as BR2_PACKAGE_OVERRIDE_FILE, I don't 
see the point... Unless you want to start overriding toolchain configs.

  Actually, I don't see much point to override the .config - why not just 
save a different .config?


  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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Any way to override .config settings?

[Steve Calfee]

On Wed, Dec 19, 2012 at 4:20 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 20/12/12 01:13, Charles Manning wrote:

>
>>>> 1) Is there a built in mechanism in buildroot to include extra symbols
>>>> and override those in .config?
>>>
>>>
>>>
>>>   Yes, the package override file: BR2_PACKAGE_OVERRIDE_FILE, defaults to
>>> $(TOPDIR)/local.mk. I use this to include a bunch of project-specific .mk
>>> files that add packages without requiring a Config.in.
>>
>>
>> In a separate thread to this, I submitted a patch that follows the
>> package overriding idea to override the config
>
>
>  Since it does exactly the same as BR2_PACKAGE_OVERRIDE_FILE, I don't see
> the point... Unless you want to start overriding toolchain configs.
>
>  Actually, I don't see much point to override the .config - why not just
> save a different .config?
>

I agree. From a maintenance point of view, having one file (.config or
defconfig) that describes how something is built is much nicer than
having a .config and various makefiles that hack at it.

Also, the buildroot make system is a mechanism that can easily be
extended by an external script or makefile. We should resist the
temptation to complicate the buildroot system just to fit a subset of
people's strange build desires. Keeping it simple and clean and
limiting the number of targets is good.

Regards, Steve

[Buildroot] Any way to override .config settings?

[Steve Calfee]

On Wed, Dec 19, 2012 at 4:46 PM, Charles Manning <cdhmanning@gmail.com> wrote:
> On Thu, Dec 20, 2012 at 1:26 PM, Steve Calfee <stevecalfee@gmail.com> wrote:
>> On Wed, Dec 19, 2012 at 4:20 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> On 20/12/12 01:13, Charles Manning wrote:
>>
>>>
>>>>>> 1) Is there a built in mechanism in buildroot to include extra symbols
>>>>>> and override those in .config?
>>>>>
>>>>>
>>>>>
>>>>>   Yes, the package override file: BR2_PACKAGE_OVERRIDE_FILE, defaults to
>>>>> $(TOPDIR)/local.mk. I use this to include a bunch of project-specific .mk
>>>>> files that add packages without requiring a Config.in.
>>>>
>>>>
>>>> In a separate thread to this, I submitted a patch that follows the
>>>> package overriding idea to override the config
>>>
>>>
>>>  Since it does exactly the same as BR2_PACKAGE_OVERRIDE_FILE, I don't see
>>> the point... Unless you want to start overriding toolchain configs.
>>>
>>>  Actually, I don't see much point to override the .config - why not just
>>> save a different .config?
>>>
>>
>> I agree. From a maintenance point of view, having one file (.config or
>> defconfig) that describes how something is built is much nicer than
>> having a .config and various makefiles that hack at it.
>
> Simplicity is pretty much my goal here too and proliferating
> defconfigs for minor tweaks seems a nasty way to tackle the issue.
>
> Some examples of where this might make sense:
>
> .config defines the project and individual developers want to apply
> tweaks to that.
> eg.1) I sometimes have problems with my svn client and only managed to
> get it working properly by forcing --username and --password. That is
> not something I want to put in a defconfig.
>
> eg2) Keeping everything the same, except changing revisions.
> eg3) Overriding sources for stuff while
>
Hi Charles,

Please keep the list in CC, others may have an opinion too.

I don't know how to deal with problems with the svn. All other things
can be handled with local custom configs. Git branches work
wonderfully for such things.

>>
>> Also, the buildroot make system is a mechanism that can easily be
>> extended by an external script or makefile. We should resist the
>> temptation to complicate the buildroot system just to fit a subset of
>> people's strange build desires. Keeping it simple and clean and
>> limiting the number of targets is good.
>
> Sorry... How is that logically consistent? A few lines back you say
> "just make more defconfigs". Now you say "limit the number of
> targets"...
>
> My proposed addition of config overriding  .config allows simple
> tweaking without generating more defconfigs. Surely that is a good
> thing?
>

Maybe, but my objection is to adding makefile targets. That affects
everyone, the docs etc. You having several configs that completely
describe your build configuration is merely something that seems
beneficial to me, maybe not you. I believe limiting the makefile
targets is a good thing, and having a few, standard ways to externally
configure your build is good enough.

Regards, Steve

[Buildroot] Any way to override .config settings?

[Charles Manning]

On Thu, Dec 20, 2012 at 2:00 PM, Steve Calfee <stevecalfee@gmail.com> wrote:
> On Wed, Dec 19, 2012 at 4:46 PM, Charles Manning <cdhmanning@gmail.com> wrote:
>> On Thu, Dec 20, 2012 at 1:26 PM, Steve Calfee <stevecalfee@gmail.com> wrote:
>>> On Wed, Dec 19, 2012 at 4:20 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>>> On 20/12/12 01:13, Charles Manning wrote:
>>>
>>>>
>>>>>>> 1) Is there a built in mechanism in buildroot to include extra symbols
>>>>>>> and override those in .config?
>>>>>>
>>>>>>
>>>>>>
>>>>>>   Yes, the package override file: BR2_PACKAGE_OVERRIDE_FILE, defaults to
>>>>>> $(TOPDIR)/local.mk. I use this to include a bunch of project-specific .mk
>>>>>> files that add packages without requiring a Config.in.
>>>>>
>>>>>
>>>>> In a separate thread to this, I submitted a patch that follows the
>>>>> package overriding idea to override the config
>>>>
>>>>
>>>>  Since it does exactly the same as BR2_PACKAGE_OVERRIDE_FILE, I don't see
>>>> the point... Unless you want to start overriding toolchain configs.
>>>>
>>>>  Actually, I don't see much point to override the .config - why not just
>>>> save a different .config?
>>>>
>>>
>>> I agree. From a maintenance point of view, having one file (.config or
>>> defconfig) that describes how something is built is much nicer than
>>> having a .config and various makefiles that hack at it.
>>
>> Simplicity is pretty much my goal here too and proliferating
>> defconfigs for minor tweaks seems a nasty way to tackle the issue.
>>
>> Some examples of where this might make sense:
>>
>> .config defines the project and individual developers want to apply
>> tweaks to that.
>> eg.1) I sometimes have problems with my svn client and only managed to
>> get it working properly by forcing --username and --password. That is
>> not something I want to put in a defconfig.
>>
>> eg2) Keeping everything the same, except changing revisions.
>> eg3) Overriding sources for stuff while
>>
> Hi Charles,
>
> Please keep the list in CC, others may have an opinion too.
>
> I don't know how to deal with problems with the svn. All other things
> can be handled with local custom configs. Git branches work
> wonderfully for such things.
>
>>>
>>> Also, the buildroot make system is a mechanism that can easily be
>>> extended by an external script or makefile. We should resist the
>>> temptation to complicate the buildroot system just to fit a subset of
>>> people's strange build desires. Keeping it simple and clean and
>>> limiting the number of targets is good.
>>
>> Sorry... How is that logically consistent? A few lines back you say
>> "just make more defconfigs". Now you say "limit the number of
>> targets"...
>>
>> My proposed addition of config overriding  .config allows simple
>> tweaking without generating more defconfigs. Surely that is a good
>> thing?
>>
>
> Maybe, but my objection is to adding makefile targets. That affects
> everyone, the docs etc. You having several configs that completely
> describe your build configuration is merely something that seems
> beneficial to me, maybe not you. I believe limiting the makefile
> targets is a good thing, and having a few, standard ways to externally
> configure your build is good enough.
>
> Regards, Steve

Sorry I didn't cc.

With a bit more fiddling I find that there is no need for an extra
CONFIG_OVERRIDE. The PACKAGE_OVERRIDE can do exactly the same (well
most of the time any way).

eg.

I can set the Linux version to HEAD in the defconfig and override that
with something else in local.mk

This also gives an "escape hatch" for doing some other stuff I want to
do (eg. make private custom packages without adding them to the main
buildroot tree).