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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
