Public SourceMage Discussion List

[Dufflebunk <dufflebunk AT dufflebunk.homeip.net>]

Hello, just some comments in defence of the current way of using
configure files.

On Sat, 2002-10-05 at 07:38, Mark Andrews wrote:
> Friday, October 4, 2002, 9:36:05 PM, Eric wrote:
> 
<snip>
> 
> I'm also questioning whether the current system of using bash scripts
> to store variables like
> 
> VARIABLE=VALUE
> 
> Is truly viable in the long term. I know for me it makes the sorcery
> code difficult to follow for debugging. I propose changing this to use
> 
> VARIABLE:VALUE
Several files do use this form, the state files in particular.

> 
> in reference tables the way my cpudetect code does. You'll be able to
> see a full set of routines for this in the next release of cpudetect
> as I'm going to create a "libvariables" for them. I'll add routines
> for writing and for parsing the entire file into bash variables to
> emulate the current system.
> 
> I suggest this for a number of reasons:-
> 
> 1) It is immediately obvious where data values are coming from.
Standard problem of flexibility vs readability. With intelegent variable
choice, not much readability should be sacrificed.

> 2) The includes in bash would only be needed for subroutines
Functions and code outside functions.

> 3) grep-ing bash code for data variables seems dodgy at best and we
> should stop this practice - currently it is the only way to get a
> single variable from a file. I suspect it is something like this that
> is causing cast to throw a funny with the autocpu code.
The colon separated format is used for exactly that kind of situation,
one where you will want to look at records individualy. The other,
sourced, format is used when you want to set all the variables.

> 
> 4) We can get the value of a variable and then override it without
> worrying that another include will change it back. We should also
> avoid silliness like archspecs being called six times for every cast.
The config files should all be using the ${VAR:-whatever} format, except
the local/config, whos values shouldn't be overridden. The archspec
thing is a bug.

> 5) bash variables can still be used where appropriate (paths?).
The colon separated files are used now where appropriate.
 
> 6) If it's good enough for the kernel routines...
The kernel routines, if you'll look at your kernel .config uses and the
Makefile, you'll notice that the Makefile includes the .config, which
looks very much like the local/config...
<snip>

> -- 
> Best regards,
>  Mark                            mailto:msasgl AT msa-enterprises.com
<snip footer>

There is a nice function you might like to use in libmisc called
explode. It's similar to the PHP explode function. It's used in several
functions that deal with files in the colon field separated format.

I will have to take a close read on your variables lib. It would be nice
to have a set of functions to deal with that stuff.

-- 


Quidquid latine dictum sit, altum sonatur. 
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1

Attachment: signature.asc
Description: This is a digitally signed message part