environment variables for ghc

[Frederik Eaton]

On Wed, Mar 09, 2005 at 08:14:24PM +0100, Tomasz Zielonka wrote:
> On Wed, Mar 09, 2005 at 10:27:28AM -0800, Frederik Eaton wrote:
> > On Wed, Mar 09, 2005 at 07:03:38PM +0100, Tomasz Zielonka wrote:
> > > 
> > > I was complaing (only to myself) that rsync doesn't allow to put some
> > > common options in ~/.rsyncrc or an environment variable. Then I simply
> > > added an alias in my .bash_profile:
> > > 
> > >     alias rsync='rsync -v --progress'
> > > 
> > > Unfortunately, this is still something that developers would like to
> > > know when facing a bug report :)
> > 
> > Right. Well, to get it to work from makefiles etc., I'd need to create
> > a script in my path, something like
> > 
> > #!/bin/sh
> > ghc -i$HSPATH -package-conf $HSPKGCONF "$@"
> > 
> > And I'd call it ghc. The thing is, I'm arguing that enough people
> > would do this that we should standardize on the environment variable
> > names. Plus, yeah, as you point out, I could just as well forget to
> > mention in a bug report that 'ghc' is my own special script.
> 
> Why not simply do:
> 
> #!/bin/bash
> /usr/.../ghc $GHCOPTS "$@"
> 
> ?

OK, that's better, but the things I said still apply.

> I am still not convinced that it is a good idea to add such
> functionality to GHC. Do you want to persuade developers of
> every program you use to add similar feature?

Is the perceived difficulty of that task an argument against improving
ghc?

> For the simple case of providing the same options everytime
> shell script wrappers and aliases are the way to go.
> 
> There are more complicated case which justify extending a program in
> such way. For example, it is common that VCS's (like CVS, subversion
> and darcs) have a single executable with many sub-commands. You them in
> this way:
> 
>     $ cvs get ...
>     $ cvs update ...
>     $ cvs status ...
> 
> You may want to provide different default options for different
> sub-commands. Possible to do with a shell script, but much, much more
> difficult. That's why at least darcs has a mechanism for setting default
> options for different sub-commands (~/.darcs/defaults or
> _darcs/prefs/defaults in a repo).

I agree that the case you're presenting is indeed more difficult, but
I don't think you're doing the estimations right for the one at hand.
The cost and annoyance of perhaps tens of thousands of people adding
and remembering to maintain wrappers named 'ghc' somewhere in their
path to accomplish this simple task (after scrounging in the
documentation to find that ghc for some reason fails to be like many
other compilers, a nontrivial cost in itself since the lack of
environment variables isn't specifically documented) - or simply not
doing so, and typing in -package-conf hundreds of times as I have
done, because they may not have write access to the main package.conf
- I think outweighs the cost of one person, once, adding central
support for environment variables, a bit of documentation in the man
page, perhaps a ghcbug program if we want super-detailed bug
reports...

Frederik

-- 
http://ofb.net/~frederik/