Cabal vs. C++

[Duncan Coutts]

On Tue, 2008-02-26 at 19:38 +1100, Roman Leshchinskiy wrote:
> What is the simplest way to build a Haskell project that uses a C++ 
> library? It needs at least the following from Cabal.
> 
>    - It must know how to compile C++ files. This kind of works by
>      accident if I list those under c-sources since gcc knows what to do
>      with them but this is (a) ugly and (b) doesn't allow me to pass
>      C++-specific options to gcc.

That's doable. To do it properly we'd have to add c++-sources and c
++-options fields. There's the question of how many languages we want to
add support for in this style.

>    - The project must be linked with g++. However, I don't understand how
>      to tell Cabal which linker to use.

That's a real pain. This kind of thing is never going to scale. When we
want to link in objective C code do we have to link using that compiler?
What if we're making a Haskell library rather than a program that needs
a C++ lib, do we have to remember that every program that uses that
Haskell package has to be linked using g++ rather than gcc? Then it's
really easy to get into the situation that different linkers are needed
if some program directly or indirectly depends on two packages that want
different linkers. It's a big ugly mess.

A hack that should work for an executable is:
ghc-options: -pgml g++

> Also, is it intentional that Cabal ignores standard 
> environment variables such as CC, CFLAGS etc.?

CC yes. CFLAGS not exactly. See:
http://hackage.haskell.org/trac/hackage/ticket/221

The reason for ignoring CC is that we use ghc as the C compiler and
linker. In future we may switch to using the system C compiler to
compile C code in which case we may want to pick up CC.
http://hackage.haskell.org/trac/hackage/ticket/229

however we'd still use ghc as the linker.

Duncan