> It's dynamic. When in doubt, remember that the Config.in format is
> nothing else than a shell script.
That's right, define_bool is definitely dynamic.
> . Have a unified pure C library providing services to back-ends:
> Parsing/checking defconfig/config.in files
> Read/write .config files, write autoconf.h file
> Read the help text associated with an option
> Variable handling (management of the dependancies)
> . Have several drop-in replacement front-ends for
> config/menuconfig/xconfig
>
> So that Linus will be happy (make config is a C program that compiles
> fast and without requiring any special library)
That is my road map, too.
> Drop-in replacement for config/menuconfig/makeconfig with the _same_
> config.in syntax, but a better check of it.
Right.
> I have already done this partly: evrything is parsed, but I have to handle
> some special cases like in the sound driver which uses
> int 'foo' CONFIG_A $CONFIG_B instead of the classical
> int 'foo' CONFIG_A 13 for example.
I think you just have to call word_eval here.
> II.1.2 second round
> Change the syntax, that will be transparent for all back-ends, thanks to
> our parsing library.
Per James Mastros' suggestion, we can change the name of the file to
something other than 'Config.in'. That way we can write our files in
parallel with the existing files, to aid in testing and transition.
mec> I think this is ungainly, but not terminally broken:
mec>
mec> if [ "$ARCH" = "sparc" -o "$ARCH" = "i386" ]; then
mec> bool "has a fnord device" Y
mec> fi
I didn't make something clear when I wrote this: this is not my proposal
for a new syntax. This demonstrates how to accomplish an architecture-
specific test with the current syntax.
I have no ideas in mind for the new syntax yet, and I don't intend to
spend any time thinking about new syntax until Phase 1, the unified
parser and front-end, is integrated into Linus's tree. That is already
a great deal of work and it is already probably too late for 2.2.
My only requirement for the new syntax is that a bison parser be able
to parse it easily.
> This particularly happens in the really broken sound driver :(
>
> My library also issue warnings for name that don't begin with CONFIG_
Regis, if you can send me diagnostics, I'm interested in fixing the
existing configuration files. Names that don't begin with CONFIG_*
are more than esthetic nuisances now; Smart Config sees configuration
variables only if they start with CONFIG_*. Also note that these
files have been fixed a lot in 2.1.87.
> Note: For the xconfig, I'm looking very hard to the GTK widget set,
> which is very easy to use with C, and which is more beautiful and a lot
> faster than TCL/TK. Moreover, we could use a "collapsable/expandable
> tree widget" to display the structure of such a config.in file.
Is GTK available under the GPL? I don't want to see a licensing
argument.
> Of course it is currently less widely spread than TCL/TK, but do we
> consider this a good reason not to use superior software?
I do. A configuration tool is less useful if the user has to install
something else first. Perhaps 'make xconfig' could bring up a TCL/TK
version. It ought to be easy to emit the same kconfig.tk that we are
emitting now. Then 'make gtkconfig' could bring up the new beautiful
gtk version. Two months later, if few people are using 'make xconfig',
then de-support it it.
> #
> # Usual comment
> #
> CONFIG_ENABLED_OPTION=y
> ##CONFIG_DISABLED_OPTION=y
> CONFIG_ANOTHER_ENABLED_OPTION=n
Please don't do this in phase 1. I want to see .config files that
look *exactly* like they used to. People can have unknown software
tools that do things with .config files.
> Any suggestions appreciated. Perhaps should we set-up a separated
> mailing-list and a home page for this project. Although my parsing lib
> is almost finished, there is still a lot of work to on back-ends.
If someone wants to set up a mailing list, go for it. But mostly
I just want to implement the phase 1 roadmap, not talk about changes
for phase 2.
Regards,
Michael Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu