-pgmc/a/l default options, other ideas
simonmarhaskell at gmail.com
Tue Jan 9 04:08:51 EST 2007
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.
More information about the Cvs-ghc