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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
