From owner-freebsd-config Tue Jan 21 20:01:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA10246 for config-outgoing; Tue, 21 Jan 1997 20:01:59 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA10217; Tue, 21 Jan 1997 20:01:44 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.4/8.8.4) id PAA03317; Wed, 22 Jan 1997 15:01:22 +1100 (EST) Message-ID: 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 References: <199701211802.DAA22042@lenlen.mt.cs.keio.ac.jp> <199701220151.MAA11082@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.56 Mime-Version: 1.0 In-Reply-To: <199701220151.MAA11082@genesis.atrad.adelaide.edu.au>; from Michael Smith on Jan 22, 1997 12:21:34 +1030 Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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/