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