[kconfig] Survival of scripts/Menuconfig?

[kconfig] Survival of scripts/Menuconfig?

[Petr Baudis]

  Hello,

  I'd like to ask if there's still a reason to keep scripts/Menuconfig in the
tree; AFAIK it's not used at all anymore, can we thus remove it? (Possibly we
could mention its existence and basic credits at the top of
scripts/kconfig/mconf.c, which is at least partially based on it?) If the
answer is yes, I'm willing to do the patch etc.

  I'm asking because I want to move the relevant lxdialog functionality to
scripts/kconfig/mconf.c (I think it makes no sense to call lxdialog externally
from mconf.c) and get rid of the separate lxdialog tree. And scripts/Menuconfig
is the only other user of lxdialog.

  Kind regards,

-- 
 
				Petr "Pasky" Baudis
.
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
                -- Graaagh the Mighty on rec.games.roguelike.angband
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

Re: [kconfig] Survival of scripts/Menuconfig?

[Roman Zippel]

Hi,

On Sun, 3 Nov 2002, Petr Baudis wrote:

>   I'd like to ask if there's still a reason to keep scripts/Menuconfig in the
> tree; AFAIK it's not used at all anymore, can we thus remove it? (Possibly we
> could mention its existence and basic credits at the top of
> scripts/kconfig/mconf.c, which is at least partially based on it?) If the
> answer is yes, I'm willing to do the patch etc.

There is more to be removed, which I plan to do with the next update.

>   I'm asking because I want to move the relevant lxdialog functionality to
> scripts/kconfig/mconf.c (I think it makes no sense to call lxdialog externally
> from mconf.c) and get rid of the separate lxdialog tree. And scripts/Menuconfig
> is the only other user of lxdialog.

What do you plan to do with it exactly?
In any case could you start with a copy of mconf.c? We are past feature 
freeze now, so it makes little sense to remove lxdialog, but it could be 
distributed separately together with the qt/gtk version.

bye, Roman

Re: [kconfig] Survival of scripts/Menuconfig?

[Petr Baudis]

Dear diary, on Sun, Nov 03, 2002 at 06:56:53PM CET, I got a letter,
where Roman Zippel <zippel@linux-m68k.org> told me, that...
> On Sun, 3 Nov 2002, Petr Baudis wrote:
> >   I'm asking because I want to move the relevant lxdialog functionality to
> > scripts/kconfig/mconf.c (I think it makes no sense to call lxdialog externally
> > from mconf.c) and get rid of the separate lxdialog tree. And scripts/Menuconfig
> > is the only other user of lxdialog.
> 
> What do you plan to do with it exactly?

After looking at it further, it turned out that the lxdialog code I want to
preserve is larger than expected, thus I will make it a library rather than
pumping all the stuff to mconf.c. Still huge advantage against having to call
the external binary everytime (also, we won't have that ugly flickering anymore
;-).

> In any case could you start with a copy of mconf.c? We are past feature 
> freeze now, so it makes little sense to remove lxdialog, but it could be 
> distributed separately together with the qt/gtk version.

Well, I think that it's not so good idea to have menuconfig distributed
separately, since it is probably the best thing you can get out of the text
mode, and there're really not much alternatives you could dream out. Having the
make config as the only way to configure the kernel is not a good thing, IMHO.

Also, as I said above, I decided to rather transform lxdialog to a library,
which is not so big change, IMHO.

-- 
 
				Petr "Pasky" Baudis
.
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
                -- Graaagh the Mighty on rec.games.roguelike.angband
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

Re: [kconfig] Survival of scripts/Menuconfig?

[Roman Zippel]

Hi,

On Sun, 3 Nov 2002, Petr Baudis wrote:

> Well, I think that it's not so good idea to have menuconfig distributed
> separately, since it is probably the best thing you can get out of the text
> mode, and there're really not much alternatives you could dream out. Having the
> make config as the only way to configure the kernel is not a good thing, IMHO.

We already have a working menuconfig, which is distributed with the
kernel. Integrating mconf.c and lxdialog is a good idea though, as it 
would give us the chance to fix some problems in the user interface.

bye, Roman