[mercury-users] Problem with mmake

[Fergus Henderson]

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 use would be entirely optional.

> 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?

Putting stuff in a configuration file would make
it more difficult to selectively override different
parts of the configuration for different processes.

> What's wrong with env MERCURY_OPTIONS='...' ./xml?
> Try typing it over and over again.  So you get lazy, and make the variable
> global, and now it applies to other programs entirely, ones to which it should
> not be applied.

You're right that setting MERCURY_OPTIONS globally is not a good idea.
But if you get tired of typing the same thing over, the right solution
is to put it in a script.

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.

> One way to handle run-time-configuration environment variables would be to
> have a compiler/linker option
> 
>     --rtenv MECURY_FROBNITZ "default"
> 
> where you would specify what environment variable name to use and what
> default value to use if it is not set.

Oh, I see what you mean -- you want a command-line option to the compiler,
not to the program being executed.  That's a good idea.

For the environment variable name, I think it might be better to just
always check `MERCURY_OPTIONS-<progname>', where <progname> is the name
of the program being invoked, before checking `MERCURY_OPTIONS'.  That way
the programmer doesn't need to remember to add --rtenv to their Mmakefile.
(The naming pattern I chose there is by analogy with Mmake's support
for target-specific Mmake variables.)

But there should be a way to set the default runtime option settings for a
program when compiling that program.  I think we could that without too much
difficulty by adding the appropriate options to `c2init'.

As part of his improvements to the profiler, Zoltan has made some
significant changes to c2init recently that he hasn't yet committed,
so to avoid cvs conflicts I'll wait until he commits those before looking
at this.  But I think it will be fairly straight-forward.

-- 
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
--------------------------------------------------------------------------