[Buildroot] Can "make <>_defconfig" rules be restored?

[Buildroot] Can "make <>_defconfig" rules be restored?

[Rick Foos]

Hi All,

I would like to use "_defconfig" files to save and restore specific defaults 
for several platforms.

The Makefile at one point supported loading of user defined "_defconfig" 
files. In the current Makefile the noconfig_targets part of "_defconfig" is 
commented out.

Is there a problem with restoring "_defconfig" file loading?

I searched the list archives on defconfig, but could not find any decision 
on this.

The following patch, restores "_defconfig" file loading limited to files at 
a maxdepth of 4.

This allows "_defconfig" files in packages and tools while avoiding the 
_defconfig files in the linux source directories.

The patch also fixes the find syntax, and allows "_defconfig" files to be in 
the same directory as make.

I'd like to propose that this patch be added, or let me know a better way to 
manage multiple default configurations.

Thanks,
Rick Foos

Index: Makefile
===================================================================
--- Makefile    (revision 9)
+++ Makefile    (working copy)
@@ -28,10 +28,9 @@

 noconfig_targets := menuconfig config oldconfig randconfig \
        defconfig allyesconfig allnoconfig release tags    \
-       source-check
+       source-check \
+       $(shell find $(TOPDIR) -mindepth 2 -maxdepth 4 -name \*_defconfig | 
sed
's|.*\/||')

-#      $(shell find . -name *_defconfig |sed 's/.*\///')
-
 # Pull in the user's configuration file
 ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
 -include $(TOPDIR).config

[Buildroot] Can "make <>_defconfig" rules be restored?

[Bernhard Fischer]

On Fri, Jun 22, 2007 at 05:04:35PM -0500, Rick Foos wrote:
>Hi All,
>
>I would like to use "_defconfig" files to save and restore specific defaults 
>for several platforms.
>
>The Makefile at one point supported loading of user defined "_defconfig" 
>files. In the current Makefile the noconfig_targets part of "_defconfig" is 
>commented out.
>
>Is there a problem with restoring "_defconfig" file loading?

Yes, the problem with this kind of _defconfig was that in a tree that
had already one or two compiled arches lying around, the find was the
cause for a delay in the order of several minutes on my box.
>
>I searched the list archives on defconfig, but could not find any decision 
>on this.

http://busybox.net/cgi-bin/viewcvs.cgi/trunk/buildroot/Makefile
revision 16763
>
>The following patch, restores "_defconfig" file loading limited to files at 
>a maxdepth of 4.
>
>This allows "_defconfig" files in packages and tools while avoiding the 
>_defconfig files in the linux source directories.
>
>The patch also fixes the find syntax, and allows "_defconfig" files to be in 
>the same directory as make.
>
>I'd like to propose that this patch be added, or let me know a better way to 
>manage multiple default configurations.

What is this _defconfig thing supposed to do? Please give an example of
what this accomplishes and how it does this.

[Buildroot] Can "make <>_defconfig" rules be restored?

[Rick Foos]

----- Original Message ----- 
From: "Bernhard Fischer" <rep.dot.nop@gmail.com>
To: "Rick Foos" <rick@synchromeshcomputing.com>
Cc: "Buildroot" <buildroot@uclibc.org>
Sent: Saturday, June 23, 2007 4:39 AM
Subject: Re: [Buildroot] Can "make <>_defconfig" rules be restored?


> On Fri, Jun 22, 2007 at 05:04:35PM -0500, Rick Foos wrote:
>>Hi All,
>>
>>I would like to use "_defconfig" files to save and restore specific 
>>defaults
>>for several platforms.
>>
>>The Makefile at one point supported loading of user defined "_defconfig"
>>files. In the current Makefile the noconfig_targets part of "_defconfig" 
>>is
>>commented out.
>>
>>Is there a problem with restoring "_defconfig" file loading?
>
> Yes, the problem with this kind of _defconfig was that in a tree that
> had already one or two compiled arches lying around, the find was the
> cause for a delay in the order of several minutes on my box.
The purpose of this patch is to have several arches lying around.

The -maxdepth 4 addresses the speed problem, and also keeps the search out 
of the kernel arch _defconfigs.
#	$(shell find . -name *_defconfig |sed 's/.*\///')
TARGETS_DEFCONFIG = $(shell find $(TOPDIR) -maxdepth 4 -name \*_defconfig | 
sed 's|.*\/||')

The defconfig target won't work for kernels, so you shouldn't pick them 
up.This will pick up from down to the packages directory.

>>
>>I searched the list archives on defconfig, but could not find any decision
>>on this.
>
> http://busybox.net/cgi-bin/viewcvs.cgi/trunk/buildroot/Makefile
> revision 16763
- andersee, what was that good for? It just slows down rebuilds as it delves 
into each sub-file needlessly.. Ripping out.
fair enough.

There weren't any other alternatives to save and restore entire 
configurations to .config. The standard way to do this appeared to be using 
defconfig.

>>
>>The following patch, restores "_defconfig" file loading limited to files 
>>at
>>a maxdepth of 4.
>>
>>This allows "_defconfig" files in packages and tools while avoiding the
>>_defconfig files in the linux source directories.
>>
>>The patch also fixes the find syntax, and allows "_defconfig" files to be 
>>in
>>the same directory as make.
>>
>>I'd like to propose that this patch be added, or let me know a better way 
>>to
>>manage multiple default configurations.
>
> What is this _defconfig thing supposed to do? Please give an example of
> what this accomplishes and how it does this.
>

I would like to handle multiple platforms and save everything from .config 
in _defconfig files. The purpose would be to pass off finished 
configurations to other development groups and for releases to a platform 
for customers. The intent is that the downstream users would have a complete 
system without further configuration for application development, testing, 
and release.

Using the _defconfig mechanism rather than copying files to .config seemed 
to be the right way to do this part of the problem. Merges from the main 
buildroot tree could continue, and the default configurations kept up to 
date through the standard defconfig method.

As a platform involves more scripting and dependencies the other definitions 
would move down to target, or package.

While target looks like a place to define platforms, target has lot of 
dependencies on other elements of target. For a platform, package actually 
has more control, and is the only place to override target setting - I don't 
see a clear answer here.

I think the way that I modifed the old code takes care of the searching 
problem, and is the most flexible way to use _defconfig files. Whether 
platforms are defined in target or platform or a new directory, the 
_defconfig method will work without further changes to the Makefile. Any 
package or target could supply defconfig.,

Since _defconfig changes the .config file, it's definition should be in the 
top level Makefile. It looks like _defconfig was intended to be this way, 
and the patch submitted resolves the issues causing it to be removed in rev 
16763.

Best Regards,
Rick Foos

[Buildroot] Can "make <>_defconfig" rules be restored?

[Ulf Samuelsson]

> >>
> >>I would like to use "_defconfig" files to save and restore specific 
> >>defaults
> >>for several platforms.
> >>
> >>The Makefile at one point supported loading of user defined "_defconfig"
> >>files. In the current Makefile the noconfig_targets part of "_defconfig" 
> >>is
> >>commented out.
> >>
> >
> > Yes, the problem with this kind of _defconfig was that in a tree that
> > had already one or two compiled arches lying around, the find was the
> > cause for a delay in the order of several minutes on my box.
> The purpose of this patch is to have several arches lying around.
> 
> 
> 
It is not particularily efficient to search the whole tree for config files.

In my private implementation, I only use the "configs" directory for
storage of such files.
make B=<board> board
will copy the latest version (they are stored as <board>-<date>.config)
to .config.
The implementation is simplistic.
Copy ALL the files to .confiug, so the latest file will overwrite all other files.



- 
Best Regards,
Ulf Samuelsson

[Buildroot] Can "make <>_defconfig" rules be restored?

[Hans-Christian Egtvedt]

On Mon, 2007-06-25 at 15:08 +0200, Ulf Samuelsson wrote:
> > >>
> > >>I would like to use "_defconfig" files to save and restore specific 
> > >>defaults
> > >>for several platforms.
> > >>
> > >>The Makefile at one point supported loading of user defined "_defconfig"
> > >>files. In the current Makefile the noconfig_targets part of "_defconfig" 
> > >>is
> > >>commented out.
> > >>
> > >
> > > Yes, the problem with this kind of _defconfig was that in a tree that
> > > had already one or two compiled arches lying around, the find was the
> > > cause for a delay in the order of several minutes on my box.
> > The purpose of this patch is to have several arches lying around.
> > 
> It is not particularily efficient to search the whole tree for config files.

The target/ directory is not that big on my snapshot (although 1 month
old):

: hcegtvedt at hcegtvedt ~/gitwork/buildroot > find target | wc -l
554
: hcegtvedt at hcegtvedt ~/gitwork/buildroot > du -sh target 
6,3M    target


> In my private implementation, I only use the "configs" directory for
> storage of such files.

Where is the configs directory, under target/configs/ ?

> make B=<board> board

Much like the
make <board>_defconfig
make

procedure would do.

> will copy the latest version (they are stored as <board>-<date>.config)
> to .config.

I.e. the save_config makefile target you talked about?

> The implementation is simplistic.
> Copy ALL the files to .confiug, so the latest file will overwrite all other files.

-- 
Mvh
Hans-Christian Egtvedt

[Buildroot] Can "make <>_defconfig" rules be restored?

[Bernhard Fischer]

On Mon, Jun 25, 2007 at 03:20:05PM +0200, Hans-Christian Egtvedt wrote:
>On Mon, 2007-06-25 at 15:08 +0200, Ulf Samuelsson wrote:
>> > >>
>> > >>I would like to use "_defconfig" files to save and restore specific 
>> > >>defaults
>> > >>for several platforms.
>> > >>
>> > >>The Makefile at one point supported loading of user defined "_defconfig"
>> > >>files. In the current Makefile the noconfig_targets part of "_defconfig" 
>> > >>is
>> > >>commented out.
>> > >>
>> > >
>> > > Yes, the problem with this kind of _defconfig was that in a tree that
>> > > had already one or two compiled arches lying around, the find was the
>> > > cause for a delay in the order of several minutes on my box.
>> > The purpose of this patch is to have several arches lying around.
>> > 
>> It is not particularily efficient to search the whole tree for config files.

That whole quirk is not efficient, that's why i don't use it but have my
configs separarately and do a simple
'make reconfigure CONFIG_DEFCONFIG=/my/foo-config'

As long as you folks don't slow down my testsuite like that (")??=% find
invocation did, i'm happy. That %_defconfig thing is something that i do
not want (and do not want to understand either), and as it doesn't hurt
me and complicates maintenance (which it doesn't from my POV), then it's
fine to apply.

I'm attaching the hunk that i am using to do something like you guy seem
to be up to (or perhaps not, dunno) for your amusement. No find, no ugly
separate dirs that reside in svn, nothing disturbing, just simply does
what it's supposed to do, and doesn't add any bloat or creeping
featureitis. I'll shut up for now.

cheers,
>
>The target/ directory is not that big on my snapshot (although 1 month
>old):
>
>: hcegtvedt at hcegtvedt ~/gitwork/buildroot > find target | wc -l
>554
>: hcegtvedt at hcegtvedt ~/gitwork/buildroot > du -sh target 
>6,3M    target
>
>
>> In my private implementation, I only use the "configs" directory for
>> storage of such files.
>
>Where is the configs directory, under target/configs/ ?
>
>> make B=<board> board
>
>Much like the
>make <board>_defconfig
>make
>
>procedure would do.
>
>> will copy the latest version (they are stored as <board>-<date>.config)
>> to .config.
>
>I.e. the save_config makefile target you talked about?
>
>> The implementation is simplistic.
>> Copy ALL the files to .confiug, so the latest file will overwrite all other files.
>
>-- 
>Mvh
>Hans-Christian Egtvedt
>
>_______________________________________________
>buildroot mailing list
>buildroot at uclibc.org
>http://busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot-reconfigure.patch
Type: text/x-diff
Size: 797 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070625/5cf2127c/attachment-0001.bin 

[Buildroot] Can "make <>_defconfig" rules be restored?

[Bernhard Fischer]

On Mon, Jun 25, 2007 at 03:40:08PM +0200, Bernhard Fischer wrote:

>me and complicates maintenance (which it doesn't from my POV), then it's
s/and complicates/and does not complicate/g
>fine to apply.

[Buildroot] Can "make <>_defconfig" rules be restored?

[Ulf Samuelsson]

> It is not particularily efficient to search the whole tree for config files.
> 
> The target/ directory is not that big on my snapshot (although 1 month
> old):
> 

The original version searched for ".", I.E: the complete tree,
and this was what my reply referred to.

> : hcegtvedt at hcegtvedt ~/gitwork/buildroot > find target | wc -l
> 554
> : hcegtvedt at hcegtvedt ~/gitwork/buildroot > du -sh target 
> 6,3M    target
> 
> 
> > In my private implementation, I only use the "configs" directory for
> > storage of such files.
> Where is the configs directory, under target/configs/ ?
> 

On top top level <buildroot>/configs

> > make B=<board> board
> 
> Much like the
> make <board>_defconfig
> make
> 
> procedure would do.
> 

How will you handle several version of the same configuration?

I would like to keep packages/target clean, so they are not updated by
the user.
The user should be able to easily generate a new configuration


> > will copy the latest version (they are stored as <board>-<date>.config)
> > to .config.
> 
> I.e. the save_config makefile target you talked about?
> 
> > The implementation is simplistic.
> > Copy ALL the files to .confiug, so the latest file will overwrite all other files.
> 
-- 
Best Regards,
Ulf Samuelsson          mail:   ulf at atmel.com
Atmel Nordic AB
Box 2033, 174 52 Sundbyberg
Kavalleriv?gen 24, 174 58 Sundbyberg
Sweden
Tel:    +46 8 441 54 22 GSM:    +46 706 224457

[Buildroot] Can "make <>_defconfig" rules be restored?

[Rick Foos]

> On Mon, Jun 25, 2007 at 03:40:08PM +0200, Bernhard Fischer wrote:
>
>>me and complicates maintenance (which it doesn't from my POV), then it's
> s/and complicates/and does not complicate/g
>>fine to apply.

If this is the patch, I would add the reconfigure target to .PHONY. There 
was a related bug on defconfig involving this.

Cheers,
Rick
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot-reconfigure-01.patch
Type: application/octet-stream
Size: 2280 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070625/9281d665/attachment.obj 

[Buildroot] Can "make <>_defconfig" rules be restored?

[Ulf Samuelsson]

> >> It is not particularily efficient to search the whole tree for config files.
> 
> That whole quirk is not efficient, that's why i don't use it but have my
> configs separarately and do a simple
> 'make reconfigure CONFIG_DEFCONFIG=/my/foo-config'
> 
> As long as you folks don't slow down my testsuite like that (")??=% find
> invocation did, i'm happy. That %_defconfig thing is something that i do
> not want (and do not want to understand either), and as it doesn't hurt
> me and complicates maintenance (which it doesn't from my POV), then it's
> fine to apply.
>
> I'm attaching the hunk that i am using to do something like you guy seem
> to be up to (or perhaps not, dunno) for your amusement. No find, no ugly
> separate dirs that reside in svn, nothing disturbing, just simply does
> what it's supposed to do, and doesn't add any bloat or creeping
> featureitis. I'll shut up for now.

Similar to my stuff.
The reason I use a separate directory, is that I do not want to specify
where the config file is located inside the command to configure.

"make reconfigure
CONFIG_DEFCONFIG=/home/ulf/projects/Buildroot/20070531/buildroot-atmel/configs/at91sam9263-2007-06-25.config"

is just a little more typing than I like.


I prefer the <board>_defconfig syntax, since this is easier
to remember than and there is therefore less likelyhood that errors
occur, I.E: less support calls.

Also the stuff does not easily lend it to updating the config file.
I can save the configuration in a new file, and this is a nice feature
I really like to have.


-- 
Best Regards,
Ulf Samuelsson