[Buildroot] svn commit: trunk/buildroot/target/linux

[Buildroot] svn commit: trunk/buildroot/target/linux

[ulf at uclibc.org]

Author: ulf
Date: 2009-01-26 20:17:06 +0000 (Mon, 26 Jan 2009)
New Revision: 25065

Log:
Replace BUILDROOT_KERNEL_CONFIG_METHOD environment variable with BUILDROOT_USE_XWINDOWS

Modified:
   trunk/buildroot/target/linux/Makefile.in.advanced


Changeset:
Modified: trunk/buildroot/target/linux/Makefile.in.advanced
===================================================================
--- trunk/buildroot/target/linux/Makefile.in.advanced	2009-01-26 19:42:47 UTC (rev 25064)
+++ trunk/buildroot/target/linux/Makefile.in.advanced	2009-01-26 20:17:06 UTC (rev 25065)
@@ -110,8 +110,8 @@
 endif
 
 # Override config method with shell variable
-ifneq ($(BUILDROOT_KERNEL_CONFIG_METHOD),)
-KERNEL_CONFIG_METHOD:=$(strip $(subst ",,$(BUILDROOT_KERNEL_CONFIG_METHOD)))
+ifneq ($(BUILDROOT_USE_XWINDOWS),)
+KERNEL_CONFIG_METHOD:=xconfig
 #"))
 else
 KERNEL_CONFIG_METHOD:=$(strip $(subst ",,$(BR2_KERNEL_CONFIG_METHOD)))

[Buildroot] svn commit: trunk/buildroot/target/linux

[Peter Korsgaard]

>>>>> "ulf" == ulf  <ulf@uclibc.org> writes:

 ulf> Author: ulf
 ulf> Date: 2009-01-26 20:17:06 +0000 (Mon, 26 Jan 2009)
 ulf> New Revision: 25065

 ulf> Log:
 ulf> Replace BUILDROOT_KERNEL_CONFIG_METHOD environment variable with BUILDROOT_USE_XWINDOWS

Why are you doing this after I explicitly said:

Let's not add any more undocumented command line options for such
special cases like this.

Renaming doesn't make it any better.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/target/linux

[Ulf Samuelsson]

m?n 2009-01-26 klockan 21:30 +0100 skrev Peter Korsgaard:
> >>>>> "ulf" == ulf  <ulf@uclibc.org> writes:
> 
>  ulf> Author: ulf
>  ulf> Date: 2009-01-26 20:17:06 +0000 (Mon, 26 Jan 2009)
>  ulf> New Revision: 25065
> 
>  ulf> Log:
>  ulf> Replace BUILDROOT_KERNEL_CONFIG_METHOD environment variable with BUILDROOT_USE_XWINDOWS
> 
> Why are you doing this after I explicitly said:
> 
> Let's not add any more undocumented command line options for such
> special cases like this.
> 

It is documented now!

BR
Ulf Samuelsson

> Renaming doesn't make it any better.
> 

[Buildroot] svn commit: trunk/buildroot/target/linux

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 ulf> Log:

 ulf> Replace BUILDROOT_KERNEL_CONFIG_METHOD environment variable with
 ulf> BUILDROOT_USE_XWINDOWS
 >> 
 >> Why are you doing this after I explicitly said:
 >> 
 >> Let's not add any more undocumented command line options for such
 >> special cases like this.
 >> 

 Ulf> It is documented now!

That doesn't make it any less of a special case.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/target/linux

[Ulf Samuelsson]

m?n 2009-01-26 klockan 22:29 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  ulf> Log:
> 
>  ulf> Replace BUILDROOT_KERNEL_CONFIG_METHOD environment variable with
>  ulf> BUILDROOT_USE_XWINDOWS
>  >> 
>  >> Why are you doing this after I explicitly said:
>  >> 
>  >> Let's not add any more undocumented command line options for such
>  >> special cases like this.
>  >> 
> 
>  Ulf> It is documented now!
> 
> That doesn't make it any less of a special case.

You are again, not only trying to establish a default behaviour
You are trying to FORCE other to accept your preferences.

I think you are really out of line.

I do not want to use menuconfig.
I do not want to update configs manually to get my preferred behaviour.

I suspect that there are others that feel the same.
Why can't you accept that!

BR
Ulf Samuelsson

[Buildroot] liblockfile version bump

[Dan Lykowski]

Would someone please bump liblockfile from 1.06.1 to 1.0.8.orig

Thanks,
Dan Lykowski

[Buildroot] liblockfile version bump

[Peter Korsgaard]

>>>>> "Dan" == Dan Lykowski <lykowdk@gmail.com> writes:

 Dan> Would someone please bump liblockfile from 1.06.1 to 1.0.8.orig

A bit more details please - Why?

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/target/linux

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> It is documented now!
 >> 
 >> That doesn't make it any less of a special case.

 Ulf> You are again, not only trying to establish a default behaviour
 Ulf> You are trying to FORCE other to accept your preferences.

Huh?

config  BR2_MAKE_XCONFIG
        bool "make xconfig (needs QT3 headers on host)"

git grep BR2_MAKE_XCONFIG=y
target/device/Atmel/at91rm9200df/at91rm9200df_defconfig:BR2_MAKE_XCONFIG=y
target/device/Atmel/at91sam9g20dfc/at91sam9g20dfc_defconfig:BR2_MAKE_XCONFIG=y
target/device/Atmel/atngw100-base/atngw100-base_defconfig:BR2_MAKE_XCONFIG=y
target/device/Atmel/atstk1005/atstk1005_defconfig:BR2_MAKE_XCONFIG=y

I don't quite see the problem.

 Ulf> I suspect that there are others that feel the same.
 Ulf> Why can't you accept that!

People disagreed to your change to make xconfig default. So far I
haven't heard anyone else than you complaining about making menuconfig
default.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/target/linux

[Ulf Samuelsson]

m?n 2009-01-26 klockan 22:48 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  Ulf> It is documented now!
>  >> 
>  >> That doesn't make it any less of a special case.
> 
>  Ulf> You are again, not only trying to establish a default behaviour
>  Ulf> You are trying to FORCE other to accept your preferences.
> 
> Huh?
> 
> config  BR2_MAKE_XCONFIG
>         bool "make xconfig (needs QT3 headers on host)"
> 
> git grep BR2_MAKE_XCONFIG=y
> target/device/Atmel/at91rm9200df/at91rm9200df_defconfig:BR2_MAKE_XCONFIG=y
> target/device/Atmel/at91sam9g20dfc/at91sam9g20dfc_defconfig:BR2_MAKE_XCONFIG=y
> target/device/Atmel/atngw100-base/atngw100-base_defconfig:BR2_MAKE_XCONFIG=y
> target/device/Atmel/atstk1005/atstk1005_defconfig:BR2_MAKE_XCONFIG=y
> 
> I don't quite see the problem.

What is the problem then with having environment variables.

Pls come up with an alternative method to enforce
behaviour of buildroot without having to resort to
editing config files.

BR 
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/target/linux

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> I don't quite see the problem.

 Ulf> What is the problem then with having environment variables.

That they are yet another way of changing config - And even worse, a
way to silently do so.

 Ulf> Pls come up with an alternative method to enforce
 Ulf> behaviour of buildroot without having to resort to
 Ulf> editing config files.

We don't have environment variables to change most other setting (And
no, please don't add them!), so I'm not convinced we need to add it
for xconfig/menuconfig, just because you prefer xconfig.

The point of having a configuration system like Kconfig is to use it.

Please look at the bigger picture, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/target/linux

[Hamish Moffatt]

On Mon, Jan 26, 2009 at 10:35:20PM +0100, Ulf Samuelsson wrote:
> m?n 2009-01-26 klockan 22:29 +0100 skrev Peter Korsgaard:
> > >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> > 
> >  ulf> Log:
> > 
> >  ulf> Replace BUILDROOT_KERNEL_CONFIG_METHOD environment variable with
> >  ulf> BUILDROOT_USE_XWINDOWS
> >  >> 
> >  >> Why are you doing this after I explicitly said:
> >  >> 
> >  >> Let's not add any more undocumented command line options for such
> >  >> special cases like this.
> >  >> 
> > 
> >  Ulf> It is documented now!
> > 
> > That doesn't make it any less of a special case.
> 
> You are again, not only trying to establish a default behaviour
> You are trying to FORCE other to accept your preferences.
> 
> I think you are really out of line.
> 
> I do not want to use menuconfig.
> I do not want to update configs manually to get my preferred behaviour.

Why don't you just pass BR2_KERNEL_CONFIG_METHOD in your own environment?
No need for extra variables and all this other stuff.

> I suspect that there are others that feel the same.
> Why can't you accept that!

Sorry Ulf, I don't think you are being reasonable. The default needs to
be the same everywhere - it doesn't make any sense to have a mix of
menuconfig and xconfig interfaces.

The current logic of trying xconfig then menuconfig is very ugly - does
it allow you to abort xconfig without falling back?

I use X and I never use xconfig.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svn commit: trunk/buildroot/target/linux

[Ulf Samuelsson]

> The current logic of trying xconfig then menuconfig is very ugly - does
> it allow you to abort xconfig without falling back?

If you could abort the xconfig without running menuconfig,
then you would not have a config file and the build would abort.
What is the sense of that?


Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/target/linux

[Hamish Moffatt]

On Thu, Jan 29, 2009 at 03:33:08PM +0100, Ulf Samuelsson wrote:
>> The current logic of trying xconfig then menuconfig is very ugly - does
>> it allow you to abort xconfig without falling back?
>
> If you could abort the xconfig without running menuconfig,
> then you would not have a config file and the build would abort.
> What is the sense of that?

You could have an exising config, start editing then change your mind.
You don't want menuconfig to launch in that case.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svn commit: trunk/buildroot/target/linux

[Ulf Samuelsson]

fre 2009-01-30 klockan 10:09 +1100 skrev Hamish Moffatt:
> On Thu, Jan 29, 2009 at 03:33:08PM +0100, Ulf Samuelsson wrote:
> >> The current logic of trying xconfig then menuconfig is very ugly - does
> >> it allow you to abort xconfig without falling back?
> >
> > If you could abort the xconfig without running menuconfig,
> > then you would not have a config file and the build would abort.
> > What is the sense of that?
> 
> You could have an exising config, start editing then change your mind.
> You don't want menuconfig to launch in that case.
> 


If you have an existing config, then buildroot will copy that
to the linux directory, and neither menuconfig or xconfig
will be launched.

It is launched if buildroot does not find a suitable config.

If you select to do make menuconfig, it will not launch  xconfig.

If you already have a .config, then you should do make linux-config
or similar.

BR
Ulf Samuelsson


> 
> Hamish

[Buildroot] svn commit: trunk/buildroot/target/linux

[Hamish Moffatt]

On Fri, Jan 30, 2009 at 12:37:27AM +0100, Ulf Samuelsson wrote:
> fre 2009-01-30 klockan 10:09 +1100 skrev Hamish Moffatt:
> > On Thu, Jan 29, 2009 at 03:33:08PM +0100, Ulf Samuelsson wrote:
> > >> The current logic of trying xconfig then menuconfig is very ugly - does
> > >> it allow you to abort xconfig without falling back?
> > >
> > > If you could abort the xconfig without running menuconfig,
> > > then you would not have a config file and the build would abort.
> > > What is the sense of that?
> > 
> > You could have an exising config, start editing then change your mind.
> > You don't want menuconfig to launch in that case.
> 
> If you have an existing config, then buildroot will copy that
> to the linux directory, and neither menuconfig or xconfig
> will be launched.
> 
> It is launched if buildroot does not find a suitable config.
> 
> If you select to do make menuconfig, it will not launch  xconfig.
> 
> If you already have a .config, then you should do make linux-config
> or similar.

OK, I misunderstood that this only affects the case where you don't have
a .config.

I still think you might want to abort xconfig and not expect it to
launch menuconfig though.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>