[mercury-users] Problem with mmake
fjh at cs.mu.OZ.AU
Fri Jun 1 14:52:43 AEST 2001
On 01-Jun-2001, Richard A. O'Keefe <ok at atlas.otago.ac.nz> wrote:
> On 31-May-2001, Richard A. O'Keefe <ok at atlas.otago.ac.nz> wrote:
> > (We could provide an environment variable, called say
> > MERCURY_DEFAULT_OPTIONS, which could be used to override this
> > for people who prefer to stick with --no-use-subdirs as the default.)
> > ARRGH! Not *another* environment variable!
> > The number of environment variables that a software system may reasonable
> > demand is ONE.
> Well, no-one would be *demanding* that you use this environment variable;
> it's [sic] use would be entirely optional.
> Oh? You mean people could get the effect they wanted without using it?
If the effect they want is to use the default options, yes.
If the defaults are well chosen that will be the case most of the time.
> > If it needs more configuration stuff, let that be in a file
> > and let the unique environment variable point to it.
> Why would that be an improvement?
> Because it would only be one environment variable.
I'm sorry, I'm still having trouble understanding why
minimizing the number of environment variables would be
I understand why you should use a hopefully unique prefix
(e.g. `MERCURY_' for the University of Melbourne Mercury implementation)
on your environment variable names, to avoid name clashes.
But I don't understand what is special about the number one that makes
it the best number of environment variables.
> Putting stuff in a configuration file would make
> it more difficult to selectively override different
> parts of the configuration for different processes.
> I can't imagine why. That isn't true for CSS or SGML catalogues or
> shell-based configuration files or .mailrc or _anything_ much that has
> an 'include' or 'source' feature. In fact, it would be far *easier* to
> override different aspects for different processes if you could set up
> several "style" files and should point to the right one with a single
> environment variable instead of having to hack lots of them.
If you want to set up "style" files, you can do it by putting
in your style files and then using `source my-style-file.style' from the shell
when appropriate. E.g.
sh -c 'source foo.style; ./foo'
This seems no harder than
env MERCURY_CONFIG=foo.style ./foo
However, if you have configuration files, and a single environment variable
which points to the current configuration file, then there's no easy way to
selectively override a single configuration setting and keep the remaining
settings unchanged. The problem is that overriding the environment variable
discards to name of the previous configuration file. To just override one
setting, you need to do something like creating a new configuration file
on-the-fly, which first includes the config file referred to in the
old setting of the environment variable and then overrides the one setting
you want to change, and then make the environment variable point to the
configuration file that you created on the fly.
> If we made it a command-line option to the program being executed,
> it would have to at very least have a long name (to avoid clashing
> with the option names for the program itself), so the repetitive typing
> problem would still arise.
> Ah, Quintus Prolog and GHC both addresses the issue of having options
> for the run-time system AND options for the applicatino in the same
> command line. It's a path that has been much trodden by other designers
> as well, and does *not* require long option names.
Hmm, well, it does seem wrong to me for the run-time system to muck
with the application's command line. However, if it works well in practice,
maybe the advantages outweigh the drawbacks, so I guess this is at least
How do Quintus Prolog and GHC tell which options are for the run-time
system and which are for the application?
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
mercury-users mailing list
post: mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-users-request at cs.mu.oz.au Message: subscribe
More information about the users