Peter Tanski wrote:
On Jan 4, 2007, at 4:53 AM, Simon Marlow wrote:
Peter Tanski wrote:
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.
For GCC and CL, the differences can be fairly major (although the fact
that CL recognises command line options with a '-' or a '/' is very
convenient). -ccflavour is a great idea.
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.
There are various ways to distinguish things in the Registry but that
involves yet more work and package.conf is also much easier for making
small, manual adjustments. So, package.conf it is; cc-flavour/
cc-flavor (accept both spellings) should be added to data BuildInfo in
Distribution.PackageDescription.
I'm probably being a bit stupid (no coffee yet this morning!), but I can't
immediately see why a new field needs to be added to BuildInfo. Could you explain?
I can imagine that we might need 'cl-options' in addition to 'cc-options',
though.
The basic setup for Win-GHC shouldn't take too long to complete. I was
close to done before Christmas, although I still don't know whether to
scrap MkDLL or modify it to use link.exe and .def files as Esa
suggested. The story is in the source code, somewhere.
Modifying it to use the MS tools seems like the right thing to do. This isn't
on the critical path, though.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
