-pgmc/a/l default options, other ideas

[Simon Marlow]

Peter Tanski wrote:
> In compiler/main/DriverPipeline.hs, runPhase sets default options  *even 
> if the user has specified a different program with the -pgm  option.  
> The example I ran into before was:
> 
> ghc -pgma yasm -opta "-ax86" -opta "-pgas" -opta "-fwin32" test.asm
> 
> In ghc, these options are stored together under 'dflags":
> 
> runPhase As stop dflags _basename _suff input_fn get_output_fn maybe_loc
>   = do    let as_opts =  getOpts dflags opt_a
> 
> runPhase continues to add particular wired-in options as if the only  
> program used is the default.  For example:
>     SysTools.runAs dflags
>         ((map SysTools.Option as_opts)
>             ++ [ SysTools.Option "-c", ... ])
> 
> This design seems to work as far as people use GHC--I am probably the  
> only complainer.  I understand the purpose of -pgm options is largely  
> to use a non-standard *location* for a default program.  An  alternative 
> design, as if any alternative program might be used,  might make users 
> responsible for adding *all* necessary options for a  user-defined -pgm 
> .  For GHC-default includes and link-libraries, GHC  might map the 
> include-opt or link-opt for the -pgm over them with  additional options, 
> such as mapping str1 or str2 from -opt_dlink str1  and -opt_dincl str2 
> over the defaults.  The order of the options  might be preserved by 
> maintaining the order of the options used in  the command line.

I don't really mind whether we allow a replacement for the string "-I" to be 
specified by an option such as -opt-dinc, or whether we simply build into GHC 
multiple "flavours" of the tools and have an option to select which one is being 
used.  For example, we might have

   -ccflavour gcc
   -ccflavour cl

to select a different command-line syntax when GHC invokes the C compiler.  If 
the syntaxes are very different, eg. requiring different ordering of options, 
then this method is to be preferred.  On the other hand, if the differences are 
minor (just renaming options) then the first method might be better.

> Ghc may test for a simple equivalence to the default pgm program in  
> runPhase (before passing it to SysTools.runAs or such).  If you  wanted 
> to test for a nonstandard program, as opposed to a nonstandard  location 
> for a default program ("/usr/local/bin/gcc" instead of  default 
> "/usr/bin/gcc"), the test would use a regex and only test the  
> equivalence of the program name ("gcc").  If the test fails, the  
> program isn't considered the default and the remaining default  options 
> will not be added in runPhase.
> 
> 
> In order to gain more flexibility in choosing the default programs  and 
> default options, particularly Microsoft CL and Yasm, I am  generating 
> those programs and options into compiler/main/Config.hs.   (As you know, 
> Config.hs is generated by compiler/Makefile.)  By the  way, I am adding 
> a simple comment in Config.hs to alert users to the  source of this 
> generated file:
> 
> -- This file is generated by compiler/Makefile --
> 
> It might be possible, even preferable, to keep the program names and  
> default options from Config.hs by storing them in a configuration  file 
> as "Simon" suggested storing them in package.conf in a comment- note in 
> SysTools.hs.  For Win-GHC (as I am calling Windows-native  GHC), it 
> would probably be more "standard" to store them in the  Registry; for 
> other systems they might be stored in package.conf or a  specialised 
> initialisation file.

The registry is a really bad place to keep configuration information - it runs 
into trouble when you want to have multiple installations.   A configuration 
file in a known place relative to the binary is much better, which is what the 
package.conf file is.

Cheers,
	Simon