Re: -pgmc/a/l default options, other ideas

Peter Tanski wrote:
> 
> On Jan 8, 2007, at 8:47 AM, Simon Marlow wrote:
> 
>> Peter Tanski wrote:
>>
>>> Good point.  There really should be both cc-options/cl-options and  
>>> cc- flavour; Cabal should check for consistency (i.e., cc-options  
>>> with cc- flavour = cl --> error).
>>
>>
>> hmm, I still don't see why you would want to specify a cc-flavour  in 
>> a package description.  Shouldn't the package be independent of  which 
>> kind of C compiler is being used by the back end?
> 
> 
> You're right.  As a build system, Cabal shouldn't need a cc-flavour:  it 
> should "guess" what platform it is on and use that (many other  build 
> systems do exactly that).  I still find the combination of cc- options 
> and cl-options without cc-flavour somewhat confusing since as  a 
> normative matter if GHC supports -cc-flavour shouldn't Cabal?  I  should 
> let the point rest until I have hashed out some real  alternatives in 
> code and see how they work.

Why does Cabal even need to know about ccflavour?  The only reason we proposed 
that GHC had a -ccflavour option is because you can change the C compiler, so 
presumably you might change the C compiler from gcc to CL.  In fact, there are 
several related issues, such as what the suffix for object files is, and GHC 
will presumably decide those on the basis of the target platform (*-windows vs. 
*-mingw32), so I think it's reasonable to hardwire the C compiler command-line 
syntax based on the target platform.  i.e. no -ccflavour option.

Cheers,
	Simon