-pgmc/a/l default options, other ideas

[Simon Marlow]

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