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

On Jan 5, 2007, at 11:54 AM, Simon Marlow wrote:
> Peter Tanski wrote:
>> On Jan 5, 2007, at 11:25 AM, Krasimir Angelov wrote:
>>> but having different fields for CL and GCC will tell to Cabal to use
>>> the cl-options field for Windows and cc-options for Linux. With
>>> cc-flavour you will force Cabal to always use CL which is  
>>> unavailable
>>> under Linux.
>>
>> I don't understand the scenario.  From what I imagined, cc-flavour
>> might specify the CL or GCC (or other) compiler and would be set
>> differently on different systems: this would be handled by the Cabal
>> 'configure' step, so the choices in the end would be
>>
>> cc-flavour:     cl      Win-GHC
>> cc-flavour:     gcc     MinGW/CygWin
>> cc-flavour:     gcc     Linux, OS X, etc.
>> ...
>>
>> Does this make sense?
>
> The problem is that we want to write Cabal packages that work both  
> with Windows and Linux, so there should be a way to have both  
> flavours of options. Eg.
>
> foo.cabal:
>    ...
>    cc-options: -DENABLE_WOOZLES
>    cl-options: /D:ENABLE_WOOZLES
>
> If you're forced to choose a ccflavour up front, you can't do this.

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).

> On the other hand, it's too much to expect everyone writing  
> packages to come up with all the different flavours of C compiler  
> options, so perhaps there should be automatic translation... ewww.   
> But most packages don't have any cc-options, so it's not so bad.

The Cabal 'configure' step should handle the automatic translation...  
This is part of the problem for Win-GHC, since Cabal does not itself  
support Windows (it is dependent on the 'make' system).  A possible  
solution would be to modify Cabal work with CMake and let CMake do  
the translation to make/nmake/Visual Studio project files.  An  
alternative might be to use Perforce-- we have been over this  
before.  The most aesthetic solution would be to build the capability  
right into Cabal but I simply don't have the time to take on yet  
another project like that right now.  It *would* be a relatively easy  
project, since it is almost entirely in Haskell.  (Sometime now I  
have to get GHC working commercially so I can use it to write  
programs with Haskell for money but being the perfectionist sort I  
would rather finish the job well for everybody than hack my own  
little solution!)

Cheers,
Pete