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

Peter Tanski wrote:
> On Jan 5, 2007, at 11:25 AM, Krasimir Angelov wrote:
>
>>>> I can imagine that we might need 'cl-options' in addition to 'cc-
>>>> options', though.
>>>
>>> If the purpose of -ccflavour is to encapsulate any number of
>>> different C compilers, then it would be easier and more general to
>>> add 'cc-flavour' to BuildInfo than to add, say:
>>>
>>> cl-options      MS CL
>>> scc-options     Sun 'CC' compiler (overlaps 'cc-options')
>>> xlc-options     IBM XL/C compiler
>>> ...
>>
>> 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.

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.

Cheers,
        Simon