[Buildroot] make linux26-force

[Buildroot] make linux26-force

[H Hartley Sweeten]

Hello,

Is there a reason make linux26-force was removed by the linux-cleanup commit?

Regards,
Hartley

[Buildroot] make linux26-force

[Thomas Petazzoni]

On Wed, 23 Jun 2010 17:59:33 -0500
H Hartley Sweeten <hartleys@visionengravers.com> wrote:

> Is there a reason make linux26-force was removed by the linux-cleanup commit?

Because I haven't seen the use case for that. Which use case does this
solve ?

The kernel already gets rebuilt whenever its .config file is changed
(by means of linux26-menuconfig, linux26-xconfig, or directly). Isn't
this enough ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] make linux26-force

[H Hartley Sweeten]

On Thursday, June 24, 2010 12:23 AM, Thomas Petazzoni wrote:
> On Wed, 23 Jun 2010 17:59:33 -0500
> H Hartley Sweeten <hartleys@visionengravers.com> wrote:
>
>> Is there a reason make linux26-force was removed by the linux-cleanup commit?
>
> Because I haven't seen the use case for that. Which use case does this
> solve ?
>
> The kernel already gets rebuilt whenever its .config file is changed
> (by means of linux26-menuconfig, linux26-xconfig, or directly). Isn't
> this enough ?

No.  Manually adding a new patch or making a change to one of the source
files will not cause the kernel to be rebuilt.  And, doing a linux26-menuconfig
also will not cause the rebuild (unless something is changed).

I'm trying to bring up a new board design so I am always making changes to
my kernel board init file, either to enable a new feature or test something.

I know I can force the rebuild by touching the stamp_configured file but
it's kind of a hassle since I was used to just doing either:

$ make linux26-force;make

Of 

$ make linux26-force;make linux26

This has worked fine for me since I started using buildroot.  The linux-cleanup
commit changed that behavior.

Regards,
Hartley

[Buildroot] make linux26-force

[Thomas Petazzoni]

Hello,

On Thu, 24 Jun 2010 10:48:09 -0500
H Hartley Sweeten <hartleys@visionengravers.com> wrote:

> No.  Manually adding a new patch or making a change to one of the source
> files will not cause the kernel to be rebuilt.  And, doing a linux26-menuconfig
> also will not cause the rebuild (unless something is changed).

True.

> I'm trying to bring up a new board design so I am always making changes to
> my kernel board init file, either to enable a new feature or test something.
> 
> I know I can force the rebuild by touching the stamp_configured file but
> it's kind of a hassle since I was used to just doing either:
> 
> $ make linux26-force;make
> 
> Of 
> 
> $ make linux26-force;make linux26
> 
> This has worked fine for me since I started using buildroot.  The linux-cleanup
> commit changed that behavior.

I understand.

In general, Buildroot is not really good at allowing people to change
the code of the different components it compiles. We had this
linux26-specific thing, but for all other regular packages, we have
nothing in place.

So, I'd prefer not to add a linux26-specific knob and have a generic
reflexion on how we want to handle this use-case, for all packages. And
in general the use-case of Buildroot being used during *development*
and not only for integration.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] make linux26-force

[Peter Korsgaard]

>>>>> "H" == H Hartley Sweeten <hartleys@visionengravers.com> writes:

Hi,

 H> No.  Manually adding a new patch or making a change to one of the
 H> source files will not cause the kernel to be rebuilt.  And, doing a
 H> linux26-menuconfig also will not cause the rebuild (unless something
 H> is changed).

 H> I'm trying to bring up a new board design so I am always making
 H> changes to my kernel board init file, either to enable a new feature
 H> or test something.

I would personally do that kind of work outside buildroot, and build the
kernel manually.

BR is nice for automating stuff once you have the basic config stable,
but I'm not the best option when you do lowlevel kernel work like board
code / device drivers.

But ok, we can readd that option - But where to stop? Some day someone
will want to hack on something else (u-boot/busybox/uClibc/whatever) and
end up in the same situation.
-- 
Bye, Peter Korsgaard