Date: Wed, 22 Jan 1997 15:01:22 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi), jkh@time.cdrom.com, keithl@wakko.gil.net, chat@freebsd.org, config@freebsd.org Subject: Kernel configuration Message-ID: <Mutt.19970122150121.davidn@labs.blaze.net.au> In-Reply-To: <199701220151.MAA11082@genesis.atrad.adelaide.edu.au>; from Michael Smith on Jan 22, 1997 12:21:34 %2B1030 References: <199701211802.DAA22042@lenlen.mt.cs.keio.ac.jp> <199701220151.MAA11082@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith writes:
> option "GPL_MATH_EMULATE" {
> description "Support for systems with no math coprocessor"
> description "(Improved but GPL-licensed version)"
> excludes {option MATH_EMULATE}
> header opt_math_emulate.h
> }
>
> I realise that we're arguing for syntaxes friendly to our chosen
> implementation languages here; I just feel that the SGML-like syntax
> is a lot harder to work with.
Agreed. The above is pretty clear, less verbose and much easier on
the eyes. I quite like it. :)
One other thing I would add is some form of option "grouping", though,
and perhaps even a way of nesting options (which might even include
support for device-specific flags). That way, a metaconfig util could
use this structure as the basis of creating configuration sections,
rather than presenting it all on the one giant dialog or a long and
arduous set of questions (like the standard Linux 'make config', which
is really *awful* and vastly improved by menuconfig/xconfig which do
have some structure).
> > 3. I want to support I18N for kernel config utility, but current
> > config system can't support these feature. For example, some
> > hackers in Japan translated comments of 2.2-BETA and 3.0-CURRENT
> > LINT file into Japanese, but I think such approach is not so smart.
>
> That's a real challenge. Short of a message catalog for every option
> file, I can't see how you could do that.
Perhaps the standard metaconfig file could be in English, and
supplimental description files supplied for other languages.
Or, following the Linux example, most if not all of the
"description" text could be external, although there's always
the danger that this becomes outdated because two files need
to be maintained rather than just one. I guess the metaconfig
tool could check that itself and issue warnings.
> Note that this is all pandering to making the status-quo easier,
> rather than chasing some blue-sky future. Is it the right thing
> to do?
The metaconfig part could remain independant of what
really runs "under the bonnet". If the actual (now generated)
config file format changes, then only that side of the
metaconfig utility changes (ie. reading and writing it).
Regardless of what happens there, I think supporting a
front-end configuration system is the right way, and adding
logic smarts to it, with help and adding some sort of coherent
structure can only make things easier.
BTW, how successful was your hunt a couple of months ago for a
good text UI builder? tcl/tk is the obvious choice for an X-based
metaconfig tool, but for textmode?
Regards,
David Nugent - Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet
davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970122150121.davidn>