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.
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).
Cabal supports Windows just fine! Cabal doesn't depend on make,
unless you ask it to. The default "simple" build system in Cabal
doesn't use make at all, it invokes all the build commands directly.
Definitely, with the caveat that Win-GHC should know how to invoke CL
even though it won't have full via-C with Haskell code. Do you know
whether the Libraries are all built with Distribution.Simple? I
could check, otherwise. As I mentioned in the email-conversation
yesterday (sorry for the glut), there are Windows-native versions of
Autoconf, Automake and Make that might be used to keep Cabal working
in the meantime. (These Windows-native versions seem to create lots
of intermediate DOS batch scripts.)
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
