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