Hi,
I see this in drivers/parport/Config.in (2.4.19) [not picking on
parport; this occurs in many places].
define_tristate CONFIG_PARPORT_PC_CML1 $CONFIG_PARPORT_PC
gcml2 (Greg Banks) checker program flags this with:
warning:drivers/parport/Config.in:18:symbol CONFIG_PARPORT_PC_CML1
Randy.Dunlap wrote:
Is there a simple, clean way to assign one tristate value to
another one? Instead of having to do something like:
if [ $CONFIG_PARPORT_PC = y ]; then
define_tristate CONFIG_PARPORT_PC_CML1 y
else
if [ $CONFIG_PARPORT_PC = m ]; then
Hi,
On Wed, 9 Oct 2002, Jeff Garzik wrote:
Well, my basic preference is
* something other than Config.new (the original name in your config system)
* something other than Config.in
I think it is a mistake to name a totally different format the same name
as an older format... even
Roman Zippel wrote:
Well, my basic preference is
* something other than Config.new (the original name in your config system)
* something other than Config.in
I think it is a mistake to name a totally different format the same name
as an older format... even config.in would be better than
Hi,
On Thu, 10 Oct 2002, Brendan J Simon wrote:
As you can see there are soo many guis to choose/use and everyone
has there favourite. I suggest that the real work be done outside of
the GUI program. ie. seperate GUI and application guts as much as
possible. I would use python as the
Hi,
On Wed, 9 Oct 2002, J.A. Magallon wrote:
stick with TCL/TK, like xconfig currently uses ?
or is it not sufficient? or just too ugly?
What is linux kernel conf written in ?
- perl: use perl-gtk (I think there is also a perl-qt)
- python: use py-gtk...
Use whatever the language
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
stick with TCL/TK, like xconfig currently uses ?
Too ugly. I actually think QT is a fine choice, I just suspect that it's
going to cause political issues.
My favourite approach by far is to actually not ship anything graphical
with the kernel at all,
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
So I think that you and Roman are close to agreement, when Roman
has the library backend ready. Of course someone needs to do a
reference implementation with it also, but it doesn't need to
ship with the kernel.
We ship BK documentation, so
On Wed, Oct 09, 2002 at 06:29:03PM +0200, Roman Zippel wrote:
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
So I think that you and Roman are close to agreement, when Roman
has the library backend ready. Of course someone needs to do a
reference implementation with it also, but it
On Wed, Oct 09, 2002 at 02:01:50PM +0200, Roman Zippel wrote:
On Tue, 8 Oct 2002, Linus Torvalds wrote:
Some things made me go eww (but on the whole details):
- I'd prefer the Config.in name, since this has nothing to do with
building, and everything to do with configuration.
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
Another suggestion about naming:
Take for example drivers/net:
cat Config.* | wc = 2149 lines
A bit a structure could be needed here.
Net.conf = Name equals directory with upper-case first letter
- Cover the whole directory, and either
Hi,
On Wed, 9 Oct 2002, Christoph Hellwig wrote:
Why don't you just separate the library from the kernel at all, making
it a similar package. We depend on a few external, kernel-specific
packages anyway, and depending on libkconfig wouldn't make the situation
worse.
The problem is that
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
ls rrunner*
should show me not only the implementation [.c + .h] but also
the configuration.
I agree with you, but only if we _always_ have one config file per driver.
Which is not necessarily the wrong thing to do.
But as long as most drivers
[Roman Zippel]
The problem is that the config syntax will continue to evolve and
currently I prefer to keep the library close to the matching config
files.
I think I can keep the basic structure constant, but new options will be
added, so IMO it's more likely that a front end works with a
On Wed, Oct 09, 2002 at 11:47:16AM -0700, Linus Torvalds wrote:
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
ls rrunner*
should show me not only the implementation [.c + .h] but also
the configuration.
I agree with you, but only if we _always_ have one config file per driver.
Which
On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
The kernel would still have the text-mode configurator.
The way I read the original post by Christoph Hellwig - nope.
If the kernel config library is outside the kernel then the
text-mode versions will fail as well.
Recall that the
16 matches
Mail list logo
